xml-dev - RE: SAX2: Namespace proposal

[Miles Sabin <msabin@cromwellmedia.co.uk>]

David Megginson wrote,
> Miles Sabin wrote,
> > This isn't necessarily the best approach. Intern'ing a 
> > string involves a lookup in a JVM-internal hash table. This 
> > table is shared across all threads, and consequently has to 
> > be locked against simultaneous reads and updates.
>
> That's probably why most parsers have their own intern 
> routines rather than using java.lang.String.intern -- at 
> least, I wrote a custom hashing and interning routine for 
> AElfred that sped it up quite significantly over (a) using 
> java.lang.String.intern() or (b) allocating a new string for 
> every element name.

Ditto, using a very nice data structure that John Cowan brought
to my attention, see,

http://www.ddj.com/articles/1998/9804/9804a/9804a.htm

which has turned out to be considerably faster than hash tables
(nb. hash tables _generally_ not just java.util.Hashtable or
java.util.HashMap) for our applications.

> If I were doing it over, though, I would actually call 
> java.lang.String.intern once for each of the strings in the 
> intern table so that they were == to the regular intern'ed 
> versions.

Try it, but I think you'll be more likely to lose than gain.

> > It's also worth remembering that you've got to _already_ 
> > have a String before you can intern it! If you've just 
> > created one (eg. from a portion of a char array) then you're 
> > only going to add overhead by doing an intern in addition.
>
> Again, I avoided this problem by building my own intern and 
> hashing methods in AElfred.  There's no reason that a hash 
> table should not be able to use an array as a key -- Java's 
> Hashtable just doesn't happen to be designed that way.

Agreed.

But all this seems to suggest that the use of java.lang.String.
intern() and java.util.Hashtable isn't that good an idea.
Insofar as SAX defines interfaces you can leave the choice to
implementors. But wiring them into the implementation of SAX 
utility classes (eg. your NSUtils) would mean that we don't
get the option.

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/


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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)