Doug Lea a écrit :
somehow 10
days
for you is the same as 2 days for the rest of us. :)
(Well, I was unexpectedly stranded at JFK for 20 hrs, but
now really am in sporadic e-mail mode for 9 days.)
More seriously, it would be great to have a HashMap that takes less memory
and
performs as well or better so I am following this with interest. If things
work
out, I'd be interested in borrowing the ideas for Scala's mutable HashMap
(an
additional thing to take into account there is the ongoing specialization
work).
Specialization should help common cases. the three of :
Strings, Integer/Long, and identity-based (no equals/hashCode override)
not only seem to together account for up to 80% of usages,
but all three would allow more space-conserving and faster solutions
in part because there is no reason to store hash codes for them.
Maybe it is worth introducing java.util.CheckedHashMap (as in my
previous note) as a relatively simple way for people to
get this better performance in Java at the expense of
having to consciously change existing constructions of
HashMap.
The other solution is to teach the VM.
We can image something that based on type profiling select
the optimized Map implementation.
I know that there is already something like that in the hotspot sources
but I haven't take a look to this part of the VM so I don't know
exactly what is done.
This would at least avoid the need for people to
use non-JDK alterantives in these cases. On the other hand,
the very low relative occurrence of programs using
IdentiyHashMap in the many cases it applies suggests that
people won't often enough use these when they should?
-Doug
Rémi
