[vector] #79: Please provide memory-footprint "complexity" information in Haddock documentation
vector
vector at projects.haskell.org
Mon Jun 18 23:12:26 BST 2012
#79: Please provide memory-footprint "complexity" information in Haddock
documentation
------------------------+---------------------------------------------------
Reporter: hvr | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Version: | Resolution:
Keywords: |
------------------------+---------------------------------------------------
Old description:
> I've been surprised lately by the base-overhead of `Data.Vector.Vector`,
> as I assumed it to be somewhere near 4+N words, but it was actually more
> like 9+N words or so for N < 128, which is a lot on 64bit archs.
>
> IMHO, it's helpful to be aware of the cost-model in advance, instead of
> having to find out the hard way via heap-profiling... :-)
New description:
I've been surprised lately by the base-overhead of `Data.Vector.Vector`,
as I assumed it to be somewhere near 4+N words, but it was actually more
like 9+N words or so for N < 128, which is a lot on 64bit archs.
IMHO, it's helpful to be aware of the cost-model in advance, instead of
having to find out the hard way via heap-profiling... :-)
--
Comment(by rl):
Note that GHC allocates additional space for boxed arrays which it uses to
mark the bits that have changed since the last GC. Updating a mutable
array would be an O(n) operation otherwise since the GC would have to
rescan the entire array. So vector should indeed add around 4 words to the
array, it's GHC that allocates more than N and for good reasons! I
wouldn't really want to precisely document these GHC internals in vector,
it seems like the wrong thing to do. Do you have an idea for something
more general?
--
Ticket URL: <http://trac.haskell.org/vector/ticket/79#comment:1>
vector <http://trac.haskell.org/vector>
Package vector
More information about the vector
mailing list