Slowness of JDK 1.1.x String.intern() [was Re: SAX, Java, and Namespaces ]

[james anderson]

(NB: I'm not a javist, so please forgive a silly question...)

What are the prospects of a form of intern which partitions the interned
string cache? if this is done, then the entire issue of namespaces disappears
for applications: they never need to "look inside" the string. A
namespace-aware parser parses to partitioned caches, an non-aware parser
parses to a single. The string "looks" ok from for the respective worldview
without further massaging, should one need to use it. If the application
wishes to intern strings it simply observes the same discipline. 

David Brownell wrote:
> 
> ...
> 
> This gives "per-parse" uniqueness, which is valuable to a fair
> degree beyond the performance win of avoiding allocating a new
> string.
> 
> However, Sun's package currently goes one step further and actually
> interns that string.  It's such a small cost (on top of the cost
> to check that array-to-string cache in the first place) that it's
> barely measurable.  (Anyone try "java -Xrunhprof:cpu=samples ..." on
> JDK 1.2/SPARC?)
> 
> That provides "per-VM" uniqueness which has turned out to be handy
> for things like stylesheet processing -- comparing strings in the
> stylesheet and source document is quite fast, and that does add
> up to a performance difference in template matching.


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 (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe 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)