[jdom-interest] RE: Reference comparisons in SAXHandler.startElement

[Joseph Bowbeer]

Philip -

I lost track of what this discussion is about.  :-)

Is it about trying to squeeze some performance out of
SAXHandler.startElement by changing a few .equals to == ?

If so, I have a hard time imaging that that micro-optimization can have much
impact because there's so much other stuff going on in
SAXHandler.startElement.  (Well, maybe it could have an impact if the
strings are fairly long and have common prefixes.)

Consider just the Element.addContent call at the end of startElement: it
does all kinds of things, including scanning all the parent element's
parents to see if the new element is among them -- which is always wasted
effort in this context because the new element was just created.

So where is this performance gain supposed to come from?

(When you post test results, can you please include the JVM version and
other platform information?  The actual test code would be nice, too, but
that might be too much trouble.  It's just that tests are so variable...)

But maybe I missed an important point somewhere.

Perhaps the most important gain of intern and == is not performance, but
memory savings, as Jason pointed out.  Or perhaps the performance gains
we're striving for are not in SAXHandler.startElement but elsewhere.

Please set me straight.  Thanks.

----- original message -----
From: GB/DEV - Philip Nelson <philip.nelson at omniresources.com>
To: jdom-interest at jdom.org
Subject: RE: Reference comparisons in SAXHandler.startElement
Date: Wed, 14 Mar 2001 15:16:34 -0600

> == is *ALWAYS* going to be faster than .equals(),
> because you  don't have to look up a virtual method,
> switch context for it, etc. The == operator is an
> atomic JVM opcode.

Yes you are right about that, intern won't make equals() go any faster.

There seems to be some disagreement about how big the hit is and when it
would hurt most.  In my tests, there was between a 14 and 20% hit for
equals().  vs ==.

>
> I also think that because the time spent context switching
> is probably the major piece of calling .equals(), a forced
> call to .intern() is going to take almost as long.  It would
> definitely be nice if we could assume the parser has
> intern()ed for us.

I suppose how often it's called and how much gain for the most typical uses
of xml will decide.  As Jason said, tests should verify these assumptions.