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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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.  What it does is assume 
  (1) efficient way to get the number of bytes previously allocated
     just by looking at the pointer
  
  (2) efficient way to determine that an in-place expansion is
      possible, and if yes, expand

| 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.


-- Gaby