You can speed up the _clear_cache, which would in probably eat up the most cycles, being called once every 30 insertions, like so:
sub clear_cache {
my @ids = sort {$count{$b} <=> $count{$a}} keys %count;
splice @ids, 0, $reset_size-1;
delete @cache{@ids};
%count = ();
@count{keys %cache} = (0) x $reset_size;
$size = $reset_size;
}
Faster to delete elements from an existing hash, I've found, than to rebuild a hash. This of course depends mostly on the ratio of deleted/total hash entries.
Also, this is isn't quite a frequency-expiration cache, since time is not a factor into the expiration routine, and you would stand a pretty good chance of getting stale cache entries that once had a bunch of hits, but remain in the cache even though they are entirely unused. I'd probably switch the count over to something like a shift-based MRU, called once every 30 fetches:
my $do_shift = 0;
sub get_elem {
my $id = shift;
if (++$do_shift == 30) {
shift_mru();
$do_shift = 0;
}
if (exists $count{$id}) {
$count{$id} |= 0x80000000;
return $cache{$id};
}
else{
return;
}
}
sub shift_mru {
while (my ($id, $count) = each %count) {
$count{$id} >>= 1;
}
}
I also seem to recall that there are ways to optimize the sorting algorithm for a return of fewer results than the total number to be sorted, but that's getting rather hairy :-)
MeowChow
s aamecha.s a..a\u$&owag.print |