Re: Caching algorithms
timasmith@hotmail.com wrote On 07/28/06 15:11,:
Hi,
Are there any standard caching algorithms for method calls.
I setup a scheme which works, but I hate to reuse it if there is
something better.
Essentially what I do is keep a Hashtable with the key the
concatenated, delimeted method name and parameters.
For example
public Object getStaticReference(int i, int j) {
String key = getKey(i,j);
if (hashtable contains key) {
return object from hashtable;
else
call method, store and return object
}
private String getKey(params...) {
String key = getCallingMethodName() + ":" + i + ":" + j;
return key;
}
What do you think?
First, I'd think that this only makes sense if the
actual computation is very expensive or is the sort
of thing that really ought not be repeated. What are
your objectives?
Second, I'd look for a less clunky key than a String.
Your example shows a pair of integers; why not write a
tiny little IntegerPair class and use that instead?
Third, I'd worry about old, stale argument/value
pairs sitting around clogging up the HashMap long after
they've outlived their usefulness, tying up gobs and
gobs of memory to no purpose. I'd want to incorporate
a cache-aging mechanism, or maybe look into one of those
WeakReferenceThingummies (I've never used 'em myself, but
I've heard vague mention of them and would research them
if I were planning to implement this sort of thing).
Fourth, I'd wonder about that getCallingMethodName()
thing. I can't think of a way to implement it with
reasonable efficiency (throwing and catching an exception
and scrutinizing its stack seems the only way). More to the
point, why should I expect the wrapped method to behave
differently when called from foo() than from bar()? And
if it behaves the same, why shouldn't I return the same
value to bar() that was computed and cached on behalf
of foo()?
Finally, I'd be very careful about using this
approach if the cached/returned objects are mutable.
That's not to say I'd completely rule out caching, just
that I'd be very cautious about it ...
--
Eric.Sosman@sun.com