According to profile on MT/SerialBench, collision rate drops significantly!
Collision rate per key lookup (min / avg / max): a. legacy IdentityHashMap (open address, linear probing): 0 / 7.4 / 75 b. new IdentityHashMap (based on HashMap, chaining): 0 / 2.8 / 5 I believe this is the reason for performance boost. No optimization for identityHashCode was done yet. I also think it makes sense to commit this implementation. Nathan, Tim, Tony, Jimmy? Thanks, Aleksey. On Mon, Apr 21, 2008 at 9:08 PM, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > So, the IdentityHashMap based on HashMap is available at HARMONY-5771. > > This change gives +20% on MT/SerialBench and +80% on MT/ThreadLocalBench. > It also incorporates arithmetic improvements [2] because HashMap > implementation already have them. > > Should we commit this code [1] and then merge the overlapping code in > AbstractMap? > > Thanks, > Aleksey. > > [1] https://issues.apache.org/jira/browse/HARMONY-5771 > [2] https://issues.apache.org/jira/browse/HARMONY-5718 > > > > On Mon, Apr 21, 2008 at 4:50 PM, Aleksey Shipilev > <[EMAIL PROTECTED]> wrote: > > Tim, > > > > I'm thinking now about making IdentityHashMap to be similar with > > HashMap. AFAIK, there are spec problems with overriding of existing > > HashMap implementation on equality operation, so I want to go this > > way: > > 1. Copy-paste HashMap implementation to IdentityHashMap > > 2. Change the equality checks and hashCode() calls to > > IdentityHashMap-specific ones > > 3. Merge the common code in AbstractMap to reduce code duplication. > > > > Performance data can be available at (2), and no committing is > > required on that step. > > > > How this sounds? > > > > Thanks, > > Aleksey. > > > > > > > > On Mon, Apr 21, 2008 at 4:45 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > Alexey Varlamov wrote: > > > > > > > 2008/4/21, Aleksey Shipilev <[EMAIL PROTECTED]>: > > > > > > > > > Well, the implementation note is what confusing me. > > > > > Can we ignore it and implement our own IdentityHashMap instead of > > > > > open-addressed + linear probed + joint key/values array? > > > > > > > > > > > > > I believe so (given that we respect other spec requirements). The > > > > implementation note is a hint, not a part of actual spec IMO. > > > > > > > > > > Before committing to replace our current implementation, I'm > interested to > > > see some experiment and measurement of new ideas. What could be done? > > > > > > Regards, > > > Tim > > > > > >
