Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Attributes performance patch

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: "Michael Kay" <mike AT saxonica.com>
  • Cc: 'Elliotte Harold' <elharo AT metalab.unc.edu>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Attributes performance patch
  • Date: Mon, 22 Nov 2004 08:41:08 -0800

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.





Archive powered by MHonArc 2.6.24.

Top of Page