Walter wrote:
> 
> After setting .length to the max reasonable size, then set .length back to
> zero. You now have a reserve that is something like the max reasonable size
> rounded up to the next bucket size.

OK.  That sounds like just the kind of feature I was requesting.  Thanks.

Justin

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkq1lf$r5v$1@digitaldaemon.com...
> Walter wrote:
> > After setting .length to the max reasonable size, then set .length back
to
> > zero. You now have a reserve that is something like the max reasonable
size
> > rounded up to the next bucket size.
>
> Hmmm. Does that mean that the amount of memory used up by arrays can never decrease?
>
> I think you should at least leave the door open for later optimization of the array memory handling so that some of the memory is freed if the used length is below a certain threshold.

I suppose the GC might (if fed enough info) know that a block holds an array, know where to get the size, and free up blocks beyond the power of two above the current use.

> That would mean, though, that the kind of reserving memory that you proposed may not work in the future. Increasing the length and then decreasing it again also looks a bit like a dirty hack - the semantics depend on the internal compiler architecture. Nothing I would want to use and certainly nothing that is easy to understand for an uninitiated programmer reading someone else's code.
>
> Is there a specific reason why you don't want to expose the reserve field? It looks like a much cleaner solution to me.

Yes, I dislike depending on implicit semantics.  Walter, are you going to set this reserve behavior in stone, or is it unspecified?

Sean

Sean L. Palmer wrote:
> I suppose the GC might (if fed enough info) know that a block holds an
> array, know where to get the size, and free up blocks beyond the power of
> two above the current use.

But what happens if the GC does this in the first iteration of the loop? Then we lose our "reservation" and end up having the inefficient case again.

Hauke

What, you want cake and want to eat it too?  ;)

I don't have an answer at present.  D could store the reserved size;  this would take a bit of space, nothing that would kill anyone.

Sean

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkrml2$4a7$2@digitaldaemon.com...
> Sean L. Palmer wrote:
> > I suppose the GC might (if fed enough info) know that a block holds an array, know where to get the size, and free up blocks beyond the power
of
> > two above the current use.
>
> But what happens if the GC does this in the first iteration of the loop? Then we lose our "reservation" and end up having the inefficient case
again.
>
> Hauke

Sean L. Palmer wrote:
> What, you want cake and want to eat it too?  ;)

<homer>

Mmmmmh. Caaake.

</homer>

> I don't have an answer at present.  D could store the reserved size;  this
> would take a bit of space, nothing that would kill anyone.

As I understand it, the current implementation already does this.

Also, I cannot think of an efficient implementation of dynamic arrays that can work with only a length field. You could only allocate exactly the length and would have to reallocate with each change of the length. Not what I'd call efficient.

So if a reserve field will be needed anyway, why not expose it to the programmer?

Hauke

Sean L. Palmer wrote:

>"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
>news:bkq1lf$r5v$1@digitaldaemon.com...
>  
>
>>Walter wrote:
>>    
>>
>>>After setting .length to the max reasonable size, then set .length back
>>>      
>>>
>to
>  
>
>>>zero. You now have a reserve that is something like the max reasonable
>>>      
>>>
>size
>  
>
>>>rounded up to the next bucket size.
>>>      
>>>
>>Hmmm. Does that mean that the amount of memory used up by arrays can
>>never decrease?
>>
>>I think you should at least leave the door open for later optimization
>>of the array memory handling so that some of the memory is freed if the
>>used length is below a certain threshold.
>>    
>>
>
>I suppose the GC might (if fed enough info) know that a block holds an
>array, know where to get the size, and free up blocks beyond the power of
>two above the current use.
>
>  
>
>>That would mean, though, that the kind of reserving memory that you
>>proposed may not work in the future. Increasing the length and then
>>decreasing it again also looks a bit like a dirty hack - the semantics
>>depend on the internal compiler architecture. Nothing I would want to
>>use and certainly nothing that is easy to understand for an uninitiated
>>programmer reading someone else's code.
>>
>>Is there a specific reason why you don't want to expose the reserve
>>field? It looks like a much cleaner solution to me.
>>    
>>
>
>Yes, I dislike depending on implicit semantics.  Walter, are you going to
>set this reserve behavior in stone, or is it unspecified?
>
>Sean
>
>
>  
>
What about other platforms. It may not always be the case that a reserve field is the most optimal technique.  Although, if there was a reserve field (but the implementation technique wasn't set in stone), then it could be ignored, I suppose.

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:bkqd4j$1c4m$1@digitaldaemon.com...
> A question: Does the GC respects any number of buckets allocated like
this?
>
> char line1[];
> line1.length = 4096;
> line1.length = 0;
>
> char line2[];
> line2.length = 4096;
> line2.length = 0;

Yes.

> I mean, if I reserve more than 1 bucket (of 1024) will still be available after allocating another array?
>
>