XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> > 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.