Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Cache misses in namespace URI verification

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] Cache misses in namespace URI verification
  • Date: Fri, 10 Dec 2004 11:58:42 -0800

I can't reproduce this with xerces-2.6.2, xom CVS and new Builder(false).build("/tmp/rddl.xml"), just using == and a cache size of 4, I get

verifier cache = hits=615, misses=5

Each call to builder.build(...) produces another 5 misses, so it seems xerces does not keep the URIs interned across builds. But that's fine and no problem. What matters is the overall hit/miss ratio, and this seems excellent.
This is using the following diagnostic help:

Verifier.java:

private static int hits = 0;
private static int misses = 0;
public static String getStats() {
return "hits="+hits + ", misses="+misses;
}

static void checkAbsoluteURIReference(String uri) {
if (cache.contains(uri)) {
hits++;
return;
}
misses++;
URIUtil.ParsedURI parsed = new URIUtil.ParsedURI(uri);

... and so on
}

URICache.java:

private final static class URICache {

private final static int LOAD = 4;
private final String[] cache = new String[LOAD];
private int position = 0;

synchronized boolean contains(String s) {
for (int i = 0; i < LOAD; i++) {
// Here I'm assuming the namespace URIs are interned.
// This is commonly but not always true. This won't
// break if they haven't been. Using equals() instead
// of == is faster when the namespace URIs haven't been
// interned but slower if they have.
if (s == cache[i]) return true;
}
return false;
}

synchronized void put(String s) {
cache[position] = s;
position++;
if (position == LOAD) position = 0;
}

}

On Dec 10, 2004, at 11:28 AM, Elliotte Harold wrote:

Wolfgang has asked me to demonstrate whether it's really necessary to use equality (equals()) comparison instead identity (==) comparison when looking for namespace URIs in Verifier's cache. Herewith are my results. The tests I'm showing here are performed with the nu.xom.benchmarks.Reproducer class run on http://www.rddl.org/. This document only uses three namespaces. The parser is Xerces 2.6.x. The VM is Apple's latest 1.4 VM. The test was run inside Eclipse, which shouldn't be a big deal since I'm only looking to see whether we're hitting th cache or not, not at the raw performance, but I'll mention that just in case it proves to be significant later.

First I added some echo printing to the URICache contains() method to check whether XOM is hitting the cache or not. Only testing for equals() here's what I see:

Cache miss: http://www.xom.nu/fakeRoot
Cache miss: http://www.w3.org/1999/xhtml
Cache miss: http://www.w3.org/1999/xlink
Cache miss: http://www.rddl.org/
Cache miss: http://www.rddl.org/
Cache miss: http://www.w3.org/1999/xhtml
Cache miss: http://www.w3.org/XML/1998/namespace
Cache miss: http://www.w3.org/1999/xhtml
Cache miss: http://www.w3.org/1999/xhtml
a lot more misses (mostly of http://www.w3.org/1999/xhtml)...
Cache miss: http://www.w3.org/1999/xhtml
Cache miss: http://www.rddl.org/
Cache miss: http://www.w3.org/1999/xlink
Cache miss: http://www.w3.org/1999/xhtml

The total was almost 700 cache misses. Now, using equals() comparison:

Cache miss: http://www.xom.nu/fakeRoot
Cache miss: http://www.w3.org/1999/xhtml
Cache miss: http://www.w3.org/1999/xlink
Cache miss: http://www.rddl.org/
Cache miss: http://www.w3.org/XML/1998/namespace

It misses exactly five times, once per URI.

Curious, I decided to see how often we're hitting the cache. I adjusted the echo printing and found we were hitting the cache 1033 times with simply an == comparison, so it's not that every namespace URI reported is a new object. Some of them are indeed interned. If I turn equals() testing back on, the cache is hit 1712 times, and missed 5 times. This is as expected (1033+684-5=1712).

This is all with a cache size of 6. Doubling the cache size to 12 only reduces the cache misses with == comparison to 656, not a significant drop. It does not appear that they're just a few extra nonidentical strings.

This is all quite surprising. It may be a bug in Xerces. It may be some unintended effect of code in XOM. It may be something I haven't yet conceived of. I will investigate further.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest





Archive powered by MHonArc 2.6.24.

Top of Page