Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Roedy Green Newsgroups: comp.lang.java.programmer Subject: Re: Did the sort do anything? Date: Fri, 13 May 2011 07:40:22 -0700 Organization: Canadian Mind Products Lines: 27 Message-ID: <2ggqs65vbuqtamqq4318v0la4hged4a3ro@4ax.com> References: Reply-To: Roedy Green NNTP-Posting-Host: RCd/Ul4tyxGUBII8WGwa5g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Forte Agent 6.00/32.1186 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4054 On Wed, 11 May 2011 21:38:26 +0100, Tom Anderson wrote, quoted or indirectly quoted someone who said : >Do you think hashCode is generally more efficient than compare? I would >have thought the opposite, because for hashCode, you have to examine all >an object's fields, whereas for a compareTo, you only have to examine as >many as it takes to find some which are different. Unless the hash is >cached, as in String. The object as a whole has a hashCode. that is just a 32 bit operation. The compare might end up comparing a number of long strings char by char. HashCodes are cached. The speed comes when it is already computed. In some cases you can tolerate a small rate of error. I would think often mistaking a no-change for a change would not be catastrophic, though the opposite normally would be. I don't think any hashCode/checksum method could guarantee 100% accuracy. -- Roedy Green Canadian Mind Products http://mindprod.com How long did it take after the car was invented before owners understood cars would not work unless you regularly changed the oil and the tires? We have gone 33 years and still it is rare to uncover a user who understands computers don't work without regular backups.