Re: [RFC] Vector (string?) growth factor of 1.5 (insted of 2)

[Dhruv Matani <dhruvbird at gmx dot net>]

On Mon, 2004-02-02 at 22:16, Paolo Carlini wrote:
> Dhruv Matani wrote:
> 
> > Have you tried for vector<pod> and vector<with_non_trivial_copy_ctor>?
> > such as std::string? How much is the difference for bot approaches with
> > 2 and 1.5 as the growth factor? Does the performance improve as the size
> > of the vector increases or does it deprove? What about memory
> > fragmentation using the specialized libstdc++-v3 allocators? Are there
> > any redundant copies made with using the specialized allocators?
> 
> For now, I'm just reading attentitevely the whole discussion (to which
> you participated, I think!)

Yes, 1 measley post!


> > Linux glibc calls mmap for large requests.
> 
> This is a suggestion that I find particularly interesting. Was also put
> forward in the thread by James Kanze. Consider that we plan to have some
> infrastructure for mmap anyway, since we want to use it when possible in
> iostreams.

I support you to the fullest. I'm a strong believer that mmap can
greatly reduce memory fragmentation on certain good systems, where it
has been implemented well.

> > Do you think that this can be worked out with Gabriel Dos Reis in
> > conjunction with the plan for allowing reallocation of memory for
> > vectors?
> 
> Dunno...

What I mean is that be aware that Gabby is working on this reallocation
thingy which assumes that the growth is 2. If you go ahead, and make the
growth 1.5 and the he also implements the reallocation, then it's quite
possible that Gabby's or your effory will not be worth it, because he
will land up expanding the original region, while you will be assuming
that the region *IS* given back and a new region *AFTER* the current
region is used (first fit) in the allocator. Thus, there is the most
possibility that the 1.5 growth factor will make performance more worst
if both of you implement your things independently!

Also, as I have mentioned earlier in the solitary post that still haunts
usenet -> vector is not the only container around. there will be many
more (inclding std::string, which has a similar usage pattern), so
restricting your assumption to the fact that vector is the only
container, and the allocator has a first fit strategy would not do
justice to all. Also, with the added complexity of the pool allocator's
usage pattern, memory wastage would also be a major concern.


-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/