> 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. 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
