harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Spark Shen <smallsmallor...@gmail.com>
Subject Re: [optimization] hashCode() evolution
Date Thu, 27 Jul 2006 14:51:09 GMT
Denis Kishenko 写道:
> Let's continue discussion about hashCode() from thread "Algorithmic 
> tricks".
>
> 2006/7/27, Spark Shen <smallsmallorgan@gmail.com>:
>> I do have a concern that in some classes, hash calculation does have
>> very import impact, but in some others may not be so important, or 
>> may not
>> be taken so heavy use. IMHO, the 'degree of hashing' provided by this
>> method may be a little too general to use by all classes. It may be too
>> heave
>> for some, but too light for others.
> Please give some examples of heavy and light hashing in your vision.
>
According to spec, lots of the classes do not override hashCode method, 
which gives a hint that these classes do not need.
And many class say explicitly that 'Returns the standard hash code as 
defined by the ||Object.hashCode()| 
<cid:part1.09070903.00050102@gmail.com>| method.'
Cited from java.lang.Character.hashCode(). Although this class has many 
internal member variable, may be its not necessary
to recalculate it's hashCode. Under this situation, the method seems a 
little heavy.

And following is cited from java.util.Locale.hashCode()
'Override hashCode. Since Locales are often used in hashtables, caches 
the value for speed.'
This is a hint that the more Locales are dispersed the better, may be 
its a little to light using a standard hash algorithm here.

Correct me if I am wrong.
>> > But only several classes are using it. I suggest integrate HashCode in
>> > all hashCode() implementations (about 200 files), I can do this. 
>> Anybody
>> > else can improve HashCode work.
>> >
>> Such a utility class is very helpful, but utilize it in all classes may
>> not be suitable. And do have some 'premature optimization' smell here.
>> As anthon said
>>
>> "What I'm talking about is not related to 'premature optimization' that
>> is now being discussed in another thread but something very narrow,
>> limited to maybe one method and not influencing anything else. "
> So your suggestion is leave hashCode as is?
>
IMHO, if there is no test cases to prove that some hash code
implementation is 'Bad', may be its too early to substitute them all.

Best regards
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Spark Shen
China Software Development Lab, IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message