Nathan, 1. Spec does not require *HashMap should be exactly of given capacity, it's just should provide the capacity requested, which obviously right if we are rounding to next 2^k. This parameter is merely a hint to collection on what size it should be ready to, nobody could (or should) guarantee the exact map capacity, it does not visible from outside, it's all implementation business.
2. This hint can dramatically improve the performance of *HashMap, as demonstrated on benchmarks. This solution is already used to boost the performance of j.u.HashMap. What do you think? Thanks, Aleksey. On Fri, Apr 18, 2008 at 8:13 PM, Nathan Beyer <[EMAIL PROTECTED]> wrote: > https://issues.apache.org/jira/browse/HARMONY-5718 > > Again, I don't agree with the capacity rounding in the patch attached to > this issue. I do like the change to the internal data structure; use two > arrays for key/value instead a single array. It makes the code easier to > read. > > > -Nathan > > On Fri, Apr 18, 2008 at 1:50 AM, Aleksey Shipilev < > [EMAIL PROTECTED]> wrote: > > > > > Colleagues, > > > > I had recently filed two JIRAs with improvements in Collections, > > giving up to +30-40% to serialization benchmarks. Presumably they will > > boost the performance across the all users since the optimization is > > pretty general: > > https://issues.apache.org/jira/browse/HARMONY-5761 > > https://issues.apache.org/jira/browse/HARMONY-5718 > > > > Would some classlib guru (Tim, Nathan, Tony?) review and commit them? > > > > Thanks, > > Aleksey. > > >
