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

[Dhruv Matani <dhruvbird at gmx dot net>]

On Tue, 2004-02-03 at 21:00, Gabriel Dos Reis wrote:
> Dhruv Matani <dhruvbird@gmx.net> writes:
> 
> | > > 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!
> 
> Right now, my working plan does not assume any constant factor or
> expansion.  

Hmmm. Sorry about that! I meant to erase that part before sending the
message, but I forgot. My mistake. The the 2 factor growth has nothing
to do with the reallocation!


> What it does is assume 
>   (1) efficient way to get the number of bytes previously allocated
>      just by looking at the pointer

Why would you want to do that? If the allocator is a standard one
(provided by the vendor), then reallocate can take 3 parameters?

>   (2) efficient way to determine that an in-place expansion is
>       possible, and if yes, expand

I would like to know how this is done, because I haven't been able to
think of a way!


> | 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.
> 
> Well, if people find the in-place expansion useful for string, great.
> But, I'm primarily interested in getting vector<> expansion as
> efficient as possible, in order to get rid of the continuous complaint
> about the sneaky VLAs.

What's VLA? Is it short for Very Large Allocation?




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