== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > dsimcha wrote: > > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > >> dsimcha wrote: > >>> Started playing w/ the implementation a little and I see a problem. What > >>> about > >>> the garbage collector? There are two possibilities: > >> [snip] > >>> The only possible solutions I see would be to have the GC know everything > >>> about > >>> the LRU cache and evict stale entries (probably slows down GC a lot, a > >>> huge PITA > >>> to implement, couples things that shouldn't be tightly coupled), or clear > >>> the > >>> cache every time GC is run (probably would make appending so slow as to defeat the > >>> purpose of having the cache). > >> I think GC.collect may simply evict the entire cache. The collection > >> cycle costs so much, the marginal cost of losing cached information is > >> lost in the noise. > >> Andrei > > > > But then you have to copy the whole array again, likely triggering another > > GC if > > the array is large. Then things really get ugly as, for all practical > > purposes, > > you've completely done away with the cache. > This happens whether or not a cache is in use. > Andrei
But the array isn't guaranteed to get reallocated immediately after *every* GC run. If you're appending to a huge array, the GC will likely run several times while you're appending, leading to several unnecessary reallocations. Each of those unnecessary reallocations will increase the memory footprint of your program, possibly triggering another GC run and wiping out your cache again in short order, until, for sufficiently large arrays, a ~= b; is almost equivalent to a = a ~ b;
