LRU cache for ~=

[Andrei Alexandrescu]

Jason House wrote:
> Andrei Alexandrescu Wrote:
> 
>> I just wrote this to Sean and Walter and subsequently discussed it
>> with Walter. Walter thinks this should work. Does anyone have the
>> time and inclination to test this out? It would involve hacking
>> into druntime's implementation of ~= (I'm not sure what the
>> function name is). I'd really appreciate this; I'm overloaded as it
>> is.
>> 
>> ==================
>> 
>> In wake of the recent demise of T[new], I was thinking of finding
>> ways of making ~= efficient for T[].
>> 
>> Currently ~= is slow because accessing GC.sizeOf(void*) acquires a
>>  global lock and generally must figure out a lot of things about
>> the pointer to make a decision.
>> 
>> Also, ~= is dangerous because it allows slices to stomp over other
>> slices.
>> 
>> I was thinking of solving these issues by keeping an LRU (Least
>> Recently Used) cache inside the implementation of ~=. The LRU would
>> only have a few entries (4-8) and would store the parameters of the
>> last ~= calls, and their cached capacities.
> 
> Shouldn't it be MRU (Most Recently Used)?

Yes. LRU would be the eviction strategy.

> I assume ~= will be disallowed for shared arrays?

I think so.

> Will all arrays overallicate when created in order to allow efficient
> appending?

Upon the first append.

> I feel like bolting on ~= to slices gives mediocre performance and a
> lot of gotchas.

You may be right about the gotchas, but you better produce some numbers 
wrt performance.

> Some users may expect slices to be reference copied
> arrays and want to see appended data in other slices. Some may get
> away with mutating the array in the MRU or a slice and seeing the
> changes, only to get bitten later. A separate type really makes more
> sense to me...

Making ~= work well for slices does not preclude creating a distinct 
library type.


Andrei