缓存java.lang.Double

Question

I have lots of Doubles in my program (notice the capital D) and I was thinking of a possible caching mechanism.

By looking at the Double constructors / factories, none is actually implementing a "cache" (like the way Integer, works, for example when using valueOf ).

I was thinking to implement such a cache by using a HashMap<String,Double> where the key is the string representation.

Any visible drawbacks / cons of such implementation?

I wonder why this wasn't done or provided yet by Java.

Answer 1

Your problem is that any possible caching mechanism will use far more memory and processor power than you are ever likely to save.

Just think of your example - creating the String, doing the map look-up, garbage collecting the String, etc.

That's a lot more work than just creating a new Double.

The HashMap itself will use a lot of memory.

Considering the number of possible Double values are you going to expire them from the cache somehow or will it keep growing for ever?

It is somewhat telling that the natural key to use into a cache of doubles would be a "new Double" itself (almost certainly faster than the String approach).

You also need to consider equality. For example try in java:

System.out.println((1-0.9)==0.1);

The result is false as the double values generated by each half are different by a miniscule fraction. But if you get a Double from your cache would you want the same Double for (1-0.9) as for (0.1) ?

So you are opening up a massive complicated can of worms, for incredibly tiny savings (in fact you are unlikely to save, most likely you will actually slow things down and use more memory not less).

The only real way to get much better efficiency is just by using double instead of Double (although I realize that's not always possible).

Answer 2

Aside from very few values (1.0, 0.0 jump to mind) there isn't such a overwhelming clustering of occurance for small integer values like there is for Integer, so its very hard to come up with a cache that has a reasonable hit rate for common applications.

Second, its not simple to cheaply detect if a Double represents to same value as another, there are edge cases with +0.0, -0.0 and NaN (possibly a few more I didn't think of). Next problem there is no convenient mapping from cached values to a simple cache structure (int maps pretty naturally to Integer[]).

Considering all these problems, there is probably simply no generally worthwhile implementation option for caching of Double values. That doesn't mean you can't come up with one for specialized cases, but before spending time on that you may want to investigate alternatives that are easier to implement / yield potentially better returns (eg double instead of Double). If its just that one HashMap, I wouldn't even bother trying to optimize unless it proved to be the bottleneck of my application.