LRUCache - a simple least recently used cache
Charles D Hixson
charleshixsn at earthlink.net
Sun Nov 4 11:35:25 PST 2007
Bill Baxter wrote:
> Charles D Hixson wrote:
>> renoX wrote:
>>> Charles D Hixson a écrit :
>>>> In the hopes that someone find this useful:
>>>> http://www.prowiki.org/wiki4d/wiki.cgi?CharlesHixson
>>>>
>>>> This particular version presumes D2.x code, but I think the
>>>> adjustments are trivial for D1.x.
>>>
>>> I think that there is a flaw in your code: the access counter is a
>>> ushort (16bit value) and is incremented each time you access an
>>> element in the cache: it can overflow quickly and will wrap around..
>>>
>> Well, two things:
>> 1) This code isn't really adapted for large sets of data. If you
>> want that, you'd better hand optimize it for your intended application.
>> 2) Whenever the cache is cleared, all the cache nodeId's are
>> decreased by the minimum nodeId (so the new minimum is zero...or one,
>> I'd need to check again. This should decrease the rate at which the
>> maximum nodeId grows.
>>
>
> I don't know why you chose to go with a short, but I have had situations
> in the past where using a short instead of an int had significantly
> worse performance. In my case it was a big array of shorts vs a big
> array of ints, so probably there was extra alignment mojo that had to
> happen to fetch data from the short array into a register and then put
> it back. But anyway CPUs seem to like working on chunks of 32-bits
> better than 16. You might try making it an int just to see how it
> performs.
>
> --bb
Well, an int seemed like overkill. I *did* consider using a
ubyte.... but that seemed like cutting things too close.
(It's certainly easy enough to change it in the code, but that
wouldn't be my preferred solution.)
More information about the Digitalmars-d-announce
mailing list