SAX2: Namespace proposal
Miles Sabin
msabin at cromwellmedia.co.uk
Mon Dec 20 15:14:52 GMT 1999
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 at cromwellmedia.com http://www.cromwellmedia.com/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list