[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [really patch] Re: HashMap putAll/putAllInternal bug

From: Stuart Ballard
Subject: Re: [really patch] Re: HashMap putAll/putAllInternal bug
Date: Mon, 13 Oct 2003 12:03:52 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030527 Debian/1.3.1-2

David Holmes wrote:
If you extend AbstractMap (why on earth would you with this
specialised implementation?) then size is defined as
entrySet().size(). From what you wrote it would appear that
entrySet().size() in your case will be a function of the size of the
front and back entrysets. Even if these are modified outside of the
main map, as long as it's not concurrent (in which case you're on your
own), then you should still be able to calculate the map size if the
front and back maps maintain their size correctly.

Sure, I can calculate the size. The problem is that doing so requires a full iteration over the elements of both sets: you can't just sum the sizes, because you have to correctly account for elements that are in both sets.

That makes this "optimization" of just looping size() times actually a pessimization, because you have to iterate over the elements twice instead of once. I didn't provide a correct implementation of size() for exactly this reason: I was afraid that it would get called a lot on the assumption that it's fast, when it's not.

As for why I need this implementation: it's being used for a language interpreter and provides an implementation of nested scoping of variables. Performance is important because it gets used a LOT. I wanted to make sure that creating a new scope was cheap and didn't affect the parent scope (it does caching to make sure that gets are cheap too). The reasons why both the front and back scope need to be able to change directly are complicated but (as far as I've found so far) unavoidable.

If you can't provide a valid implementation for any concrete method
that you are supposed to implement, then it seems quite unreasonable
of you to expect any inherited methods to work for you. I think it
quite reasonable for a method like putAll to expect to be able to use
any of the non-optional methods of Map/Set/Iterator to do its job -
even if it doesn't document exactly which methods it uses.

True, except that I would think it's reasonable to expect the implementations to be optimized for the general case, not under a mistaken assumption that size() is fast. If I were to provide a correct implementation of size(), I'd be even more concerned about this issue because then it would be an important performance problem that would be really hard to diagnose.


Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126

reply via email to

[Prev in Thread] Current Thread [Next in Thread]