xml-dev - Re: String interning (WAS: SAX2/Java: Towards a final form)

[Tyler Baker <tyler@infinet.com>]

Miles Sabin wrote:

> David Brownell wrote,
> > Literals are already interned.  It's in the language
> > spec. Look at the javadoc for java.lang.String.intern ()
>
> Good point ... and one which I'd <blush>unaccountably
> overlooked</blush>.
>
> I don't think this materially affects my argument tho',
> because the only time where the performance difference
> between,
>
>   foo == "literal"
>
> and,
>
>   foo.equals("literal")
>
> is going to be significant is where there are long chains
> of comparisons, ie.,
>
>   if(foo == "elem1")
>     // do stuff for elem1
>   else if(foo == "elem2")
>     // do stuff for elem2
>
>   // ... repeat many times ...
>
>   else if (foo == "elemn")
>     // do stuff for elemn
>
> where it'd be a far better idea (both from performance and
> software design POVs) to do something like,
>
>   ElementHandler handler =
>     (ElementHandler)someTable.lookup(foo);
>
>   handler.doStuffForElement();

In general you are right except that calculating a hashcode and then doing one or two
equality tests in the hash table lookup method actually take more time than doing 20 or so
identity tests. Really I guess it depends on your architecture. Also, in some of the XML
related software I have written, I have used a specialized interned String map for optimal
performance when I need to write code similiar to what you have suggested. For example, in
an XML Parser I used it to map element names to element type objects when going through
the validation process as for each element name you need to look up the properties of that
element in the appropriate element type object (which may be part of a greater DTD object)
to do the necessary validation. Using java.util.HashMap just happened to be wayyyyyyy
toooooo slow for my needs at the time.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.