You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Denis Kishenko <dk...@gmail.com> on 2006/07/27 16:04:41 UTC
[optimization] hashCode() evolution
Let's continue discussion about hashCode() from thread "Algorithmic tricks".
2006/7/27, Spark Shen <sm...@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.
> > 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?
---------------------------------------------------------------------
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
Re: [optimization] hashCode() evolution
Posted by Spark Shen <sm...@gmail.com>.
Denis Kishenko 写道:
> 2006/7/28, Alexey Petrenko <al...@gmail.com>:
>> 2006/7/27, Denis Kishenko <dk...@gmail.com>:
>> > Unfortunately
>> > 1. class can has temporary private fields (see BasicStroke.java)
>> We can mark such fields as transient. As for serialization.
>>
>> > 2. class can has final fields which take part in hash code calculation
>> > (see EllipticCurve.java)
>> It's probably the reason to add final fields to hash code calculation.
>
> Yep, we can do this, but as you remember Alex suggested use Eclipse
> tool to make hashCode automatically - it would be easier. But before
> run this tool we have to made a lot of routine work =)
>
Agree. I think using automatic tool is a better way than using
hashCode.append() diagram for most of the classes.
And if there is specific need, customizing hash code calculation is
necessary.
Best regards
> Alex's suggestion
> "Lastly, an easier approach is to use a tool (such as Eclipse) to
> generate the implementation of hashCode() automatically based on the
> non-static, non-final variables of a class. This one sounds like (a)
> the easiest, and (b) all-round better performant than any of the
> above."
>
> ---------------------------------------------------------------------
> 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
Re: [optimization] hashCode() evolution
Posted by Denis Kishenko <dk...@gmail.com>.
2006/7/28, Alexey Petrenko <al...@gmail.com>:
> 2006/7/27, Denis Kishenko <dk...@gmail.com>:
> > Unfortunately
> > 1. class can has temporary private fields (see BasicStroke.java)
> We can mark such fields as transient. As for serialization.
>
> > 2. class can has final fields which take part in hash code calculation
> > (see EllipticCurve.java)
> It's probably the reason to add final fields to hash code calculation.
Yep, we can do this, but as you remember Alex suggested use Eclipse
tool to make hashCode automatically - it would be easier. But before
run this tool we have to made a lot of routine work =)
Alex's suggestion
"Lastly, an easier approach is to use a tool (such as Eclipse) to
generate the implementation of hashCode() automatically based on the
non-static, non-final variables of a class. This one sounds like (a)
the easiest, and (b) all-round better performant than any of the
above."
---------------------------------------------------------------------
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
Re: [optimization] hashCode() evolution
Posted by Spark Shen <sm...@gmail.com>.
Denis Kishenko 写道:
> Let's continue discussion about hashCode() from thread "Algorithmic
> tricks".
>
> 2006/7/27, Spark Shen <sm...@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()|
<ci...@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