[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: classpath ./AUTHORS ./ChangeLog java/util/HashM...
From: |
Bryce McKinlay |
Subject: |
Re: classpath ./AUTHORS ./ChangeLog java/util/HashM... |
Date: |
Tue, 18 Sep 2001 20:39:58 +1200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 |
Tom Tromey wrote:
"Eric" == Eric Blake <address@hidden> writes:
Eric> Modified files:
Eric> . : AUTHORS ChangeLog
Eric> java/util : HashMap.java Hashtable.java
Eric> * java/util/Hashtable.java (contains): check for null
Eric> (Hashtable(Map)): more efficient
Eric> (clear): more efficient
Eric> (clone): more efficient, by adding Entry.copy
I think it is disputable whether these are really more efficient.
I'm not too concerned with `clear'. In that case the new code may
very well be more efficient. It is hard to say in a
platform-independent way.
I don't agree with the change to 'clear'.
@@ -389,10 +400,7 @@
public synchronized void clear()
{
modCount++;
- for (int i=0; i < buckets.length; i++)
- {
- buckets[i] = null;
- }
+ buckets = new Entry[buckets.length];
size = 0;
}
Creating a whole new array is an expensive operation. In addition to the
cost of the allocation itself (typically this requires synchronization
on a global heap lock), it creates more garbage for the collector to
deal with (increasing GC frequency), and potentially uses more memory by
causing the heap to expand. In contrast, a small, tight loop like the
one above should execute very fast on any modern cpu (assuming a JIT and
taking cache behaviour into account), so unless buckets.length is very
large, its hard to imagine that it could be less efficient.
Any contradictory opinions?
regards
Bryce.