Cart
[Home] [By Thread] [By Date] [Recent Entries]
(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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
