XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Nov 22, 2004, at 4:04 AM, Michael Kay wrote:

> Back in my assembler days, we always counted down where possible 
> because
> comparing with zero took one instruction and comparing with anything 
> else
> took two. But heaven only knows whether that's a universal truth!
>
> Michael Kay

That's still true as it was 20 years ago when I did assembler on a 
Commodore PET 2001 with 2 KB memory.

If is makes a real difference is another question. I guess it makes 
Java compiler optimizations easier, in particular range checks and null 
pointer checks that can be hoisted outside the loop due too safe loop 
invariants, allowing for alternative code generation, and possibly 
better inlining. Less speculative code generation to do for the 
compiler.

The other point is that given that an element rarely has more than 2 
attributes, I suspect that the the temporary iterator allocation and 
additional memory accesses in its methods destroy cache locality.

A precise answer is difficult because compiler optimizations are often 
non-linear, resulting in benefitial chain reactions. It is quite 
possible that a small seemingly innocent change (or two or three) can 
have a large effect, but as always, it's a moving target.

> if there really is a hotspot, i would investigate, why the iterator is 
> a
> problem here.
> tja - here might be a problem: the iterator checks for concurrent
> modifications,
> the index-access doesnt. What if two calls to Attributes.add() happen 
> at
> the same time?
> What if Attributes.remove() is called while an add() is under way??

Such a program is non-deterministic, and will most likely fail in 
unpredictable manners anyway.
Quite appropriately, there's no thread-safety for such XOM usage.

Wolfgang.