version(ctfe)

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> Leandro Lucarella wrote:
>>> Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
>>>> For relatively large chunks of memory, the GC keeps a control block.
>>>> We could add a member size_t requestedSize that keeps the size that
>>>> was requested with an allocation/reallocation call. The GC can take
>>>> initiative in overallocating memory and expose primitives such as
>>>> requestedSize (how much did the program ask for?) and capacity (how
>>>> much is really allocated?).  With that API, it is possible to
>>>> implement ~= efficiently.
>>> That would mean moving the overhead of arrays to the GC, but that overhead
>>> will be present for *all* objects, arrays or not, so I don't think it will
>>> be a good idea...
>> I forgot to mention that ~= would also have a means to communicate the
>> GC to overallocate. My point is simple: the problem is that slices don't
>>   store enough info. That info could get in the memory control block.
> 
> This is the part of this thread I'm not understanding:  Isn't this info stored
> already?  The only problem is querying it is slow.  See GC.sizeOf(), and bug 2900.
>  (2900 is fixed, but it's still slow, and there's still bug 2093.)  What are you
> proposing that's different from the status quo?

Sorry, I got confused a bit: you have the size in the array and you can 
get the capacity from the GC, just slowly. Let's sleep on this some 
more, it may not be impossible to find a growth scheme that works fast.

Andrei