Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #39127
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Best way to make a hashcode? |
| Date | 2019-08-27 11:49 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <qk3jf9$s8n$1@dont-email.me> (permalink) |
| References | <89cadee9-0108-4c76-9e94-c8f716290582@googlegroups.com> <qk1jmg$8ck$1@dont-email.me> <11fd675f-2de2-49a1-baee-b77c2c8d8775@googlegroups.com> <qk3bq2$fh9$1@dont-email.me> <cbde76cd-4227-4f2c-b33f-54d8c3edebeb@googlegroups.com> |
On 8/27/2019 10:29 AM, Eric Douglas wrote:
> On Tuesday, August 27, 2019 at 9:39:24 AM UTC-4, Eric Sosman wrote:
>> I'm not familiar with POI, but this sounds expensive: Why create
>> (most likely) a StringBuilder and several Strings just to compute a
>> hash value? Remember, the reason for wanting a hash value in the
>> first place is because you need speed; don't burn extra cycles on
>> making and collecting needless garbage. (Does the toString() in
>> this case produce an entire XML document? Oh, Lordy!)
>>
>> You'd also need to be concerned about the "invariance" of the
>> String representations of the component sub-objects. If the Strings
>> change with locale or look-and-feel or something, the hash codes
>> could also change and mess up everything. Even the mere passage of
>> time might do it: A date that renders as "today" might spontaneously
>> change to "yesterday" as midnight passes ...
>>
>> If you're *sure* the String representations are invariant, and if
>> you're *confident* that they're not too costly, well, okay, maybe.
>>
>> --
>
> It extends XmlObject not document. That returns all properties that have value. By default that could look like
> <xml-fragment borderId="21" applyBorder="true"/>
>
> I expect these fragments will still match if you change the locale, assuming all the xml objects you're mapping still have the same locale.
> The advantage is you can add more properties without changing the hashcode method. This would also mean your objects can match if they're generated from 2 different versions of the API as long as they only reference fields available in both.
>
> Does calling the toString() which calls toPrettyString() iterating over every non-null property to return a single String hashcode add significantly more overhead than the single String to int computation we see in the hashcode generated if we right click the class and select generate hashcode in Eclipse? Any chance they were thinking about mixing versions with the POI, or more likely they wanted to change the property fields without updating the hashcode method?
(Repeating: I'm not familiar with POI, so take my opinions as
guesses rather than as Gospel.)
The generated hashCode() exhibited up-thread computed the hash of
an *existing* String value. It expended no cycles in generating or
collecting a new String, and performed the hash calculation only the
first time it was asked for (unless it was extraordinarily unlucky).
Note that last point: Somebody felt hash speed was important enough
to warrant caching the hash value of a simple String.
The iteration you describe appears to create a brand-new String
every single time, quite likely more than one as the individual
pieces are generated and concatenated. Then there's a StringBuilder
to think about, too, and the (several?) char[] arrays that underlie
it as it grows. Finally, calling hashCode() on the brand-new String
will be the first such call and thus will compute the hash afresh.
So, yes: It's "significantly more overhead" (unless you've left
out a bunch of mitigating detail).
As for why the Apaches chose this seemingly inefficient way to
compute hashes -- well, "I'm not familiar with POI," and certainly
not familiar with the thinking of its developers. Maybe they figured
"Nobody in his right mind would use these things as hash keys anyhow"
and opted for minimal development time, or maybe there's more going
on than is apparent from your brief description, I dunno.
--
esosman@comcast-dot-net.invalid
Five hundred twelve days to go.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Best way to make a hashcode? Eric Douglas <e.d.programmer@gmail.com> - 2019-08-26 13:51 -0700
Re: Best way to make a hashcode? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-26 17:41 -0400
Re: Best way to make a hashcode? Eric Douglas <e.d.programmer@gmail.com> - 2019-08-27 06:24 -0700
Re: Best way to make a hashcode? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-27 09:39 -0400
Re: Best way to make a hashcode? Eric Douglas <e.d.programmer@gmail.com> - 2019-08-27 07:29 -0700
Re: Best way to make a hashcode? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-27 11:49 -0400
Re: Best way to make a hashcode? Eric Douglas <e.d.programmer@gmail.com> - 2019-08-27 11:05 -0700
Re: Best way to make a hashcode? Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-27 15:16 -0400
Re: Best way to make a hashcode? Eric Douglas <e.d.programmer@gmail.com> - 2019-08-27 13:04 -0700
Re: Best way to make a hashcode? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-08-27 23:51 +0200
Re: Best way to make a hashcode? Silvio <silvio@internet.com> - 2019-08-28 01:27 +0200
Re: Best way to make a hashcode? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-09-06 19:42 +0200
Re: Best way to make a hashcode? Arne Vajhøj <arne@vajhoej.dk> - 2019-08-26 19:03 -0400
Re: Best way to make a hashcode? Eric Douglas <e.d.programmer@gmail.com> - 2019-08-27 04:59 -0700
Re: Best way to make a hashcode? Arne Vajhøj <arne@vajhoej.dk> - 2019-08-27 21:08 -0400
Re: Best way to make a hashcode? ross.finlayson@gmail.com - 2019-09-05 20:27 -0700
Re: Best way to make a hashcode? trisha guillot <guillottrisha347@gmail.com> - 2020-01-18 07:25 -0800
csiph-web