Re: Status of == vs equals() RESULTS

2010-08-09 Thread Clive Brettingham-Moore
Have to agree .equals is the way to go, since correctness of == is too reliant on what must be considered implementation optimisations in the parser. Benchmarking in JVM is notoriously difficult, but it does look like there is no gross difference, which should kill any objections to doing it corre

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Chad La Joie
I guess I didn't explicitly say this, but if, after a few days, people can't suggest an issue with this testing methodology or provide testing inputs that show different results, I'll rip out the helper class I added and just use equals() everywhere. That'll make the code a lot nicer to read.

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Chad La Joie
On 8/9/10 11:13 AM, Pellerin, Clement wrote: In JDK 1.5, String.equals() begins with: public boolean equals(Object anObject) { if (this == anObject) { return true; } ... Since String is a final class, the JIT compiler is free to in-line String.equals() Thi

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Chad La Joie
On 8/9/10 11:10 AM, Raul Benito wrote: I did mine with --server and sometimes with more memory but it is really strange, what version of the JRE are you using? What optimizations in particular did you want to take advantage of using --server? Did you see anything to suggest that it was run

RE: Status of == vs equals() RESULTS

2010-08-09 Thread Pellerin, Clement
In JDK 1.5, String.equals() begins with: public boolean equals(Object anObject) { if (this == anObject) { return true; } ... Since String is a final class, the JIT compiler is free to in-line String.equals() This is such a common case, I bet the JIT compiler t

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Raul Benito
On Mon, Aug 9, 2010 at 4:45 PM, Chad La Joie wrote: > > > On 8/9/10 10:40 AM, Raul Benito wrote: > >> What command line options did you use? >> > > No options. > > I did mine with --server and sometimes with more memory but it is really strange, what version of the JRE are you using? Regards,

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Chad La Joie
On 8/9/10 10:45 AM, Chad La Joie wrote: My testings were more reliable if use 100 warms-up let the jit run its magic, and then go for the timed test. Okay, I try that. It made no difference. -- Chad La Joie http://itumi.biz trusted identities, delivered

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Chad La Joie
On 8/9/10 10:40 AM, Raul Benito wrote: What command line options did you use? No options. My testings were more reliable if use 100 warms-up let the jit run its magic, and then go for the timed test. Okay, I try that. Also are you running both tests in the same invocation if you do, the

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Raul Benito
Hello Chad, What command line options did you use? My testings were more reliable if use 100 warms-up let the jit run its magic, and then go for the timed test. Also are you running both tests in the same invocation if you do, the second will be handicap, as the first one will be just inline the se

Re: Status of == vs equals() RESULTS

2010-08-09 Thread Chad La Joie
So, I have some unexpected results from this work. I implemented a helper class that checked the equality of element local names, attribute local names, namespace URIs, and namespace prefixes (i.e. everything that Xerces always interns). Then I made sure to replace all == != and equals() that