Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] profiler

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] profiler
  • Date: Wed, 24 Nov 2004 14:16:31 -0800

Any good ideas should be welcome. If one can figure out how to effectively bound the cache and maintain high hit ratio it would be interesting.

A synchronized HashSet would let us have O(1) insertion and lookup, but I'm not sure what the constant time performance would be like.

Bounding the set is tricky. We could just pick some number like 1024 for the set's upper bound, and clear it every time that value is reached. Or maybe allow it to be set by a system property, or some such.

The real question is whether the constant time retrieval from the set would be larger than just checking the names manually. Namespace URLs are expensive to check because:

1. They're quite long
2. The algorithm for checking them is quite involved, and creates lots of temporary strings.

Element names, in practice, are much shorter than namespace URIs and the algorithm for checking them is much simpler, and does not create any temporary objects. It just blasts through the string checking each character against a lookup table.

My gut feeling is that a cache would not be faster here, but I could be wrong about that.

My gut feeling is also that it's tough.
One could try using a HashMap (better: LinkedHashMap with fixed LRU bounding) on qnames (rather than localnames or prefixes). Can cover two checks at once, and it might just work if the qnames passed to the constructor commonly are constants or come from a string-interning source: in that case hashcodes are cached by String itself, and String.equals reduces to ==, and hashmap can have very low constant overhead.

BTW, now that URICache uses == you might want to enlarge the cache size from 4 to, say 6. covers more cases without trashing and it's very fast anyway.

Another, unrelated thing to note is that JDK 1.5 nomore does String.subString() sharing. It's good news since it can eliminate hidden memory leaks, and it's bad news since it can produce tons of memory overhead where code implicitly assumes that substrings are shared. For example, Element.prefix and Element.localName come to my mind. Even if a prefixed qname is constant, new copies are generated by the internal design of Element, and, worse, semi-permanently stored in Element. Same for Attribute.

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page