Oooh, ooh, pick me!
Josh
P.S. It isn't as tedious as you think. Doing the obvious transformation on
HashMap gives you a benchmark. Then you try to beat it.
On Mon, Jun 9, 2008 at 3:01 PM, Martin Buchholz <[EMAIL PROTECTED]> wrote:
> Osvaldo, I fundamentally agree with you that
> opti
Doug Lea wrote:
I don't think so. Relaying the subset methods to the *Set classes
was just an implementation expediency under the mis-thought that they
would take care of recursive subsets etc rather than needing
special implementations for KeySets. But the byproduct for remove()
is clearly wrong
Osvaldo,
Yes, I must say that I'm surprised that my original implementation of
HashSet still stands. It would be interesting to see what sort of
performance improvement (time and space) we could get with a freestanding
HashSet implementation.
Josh
On Mon, Jun 9, 2008 at 2:09 PM, Osvaldo Pi
Osvaldo, I fundamentally agree with you that
optimizing HashSet in the manner you describe
is worthwhile, but because the implementation
needs to "parallel" HashMap, it would be good
to do this after the current hacking activity on
HashMap quiesces.
Unfortunately, this kind of programming
is pure
Martin Buchholz wrote:
TreeMap.navigableKeySet().subSet(x,y).remove(o)
fails because TreeMap.KeySet.subset calls the
TreeSet(NavigableMap)
constructor
Thanks for finding this!
In the case of ConcurrentSkipListMap, the correctness
issue is even more serious, since remove(existing element)
fai
Doug and Josh and Chris,
(Chris, please file a bug)
TreeMap.navigableKeySet().subSet(x,y).remove(o)
fails because TreeMap.KeySet.subset calls the
TreeSet(NavigableMap)
constructor, and that requires an argument map
not containing arbitrary value objects for correctness.
This correctness is probab
