XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

Back from vaction. I'll take all your questions together in one mail:

On Nov 27, 2004, at 1:16 PM, Elliotte Harold wrote:

> Wolfgang Hoschek wrote:
>
> > Small suggestion ("fruit hanging low"):
> > 12% speedup in ParentNode.java for changing the static declaration of 
> > childen from a List to an ArrayList (which it is anyway):
> > ParentNode.java:
> >     ArrayList   children;
> >     //List   children;
>
> That's easy enough to do, and doesn't really harm anything. It's a 
> minor code smell at worst. However in my tests this had no noticeable 
> effect. Can anyone explain why this might have such a dramatic effect? 
> i.e is there any theoretical reason to believe this is a good idea? Is 
> this likely to be very different from one VM to another? Is this 
> something that might make a big difference in 1.5 and not 1.4? or the 
> server VM and not the client?

It can only be benefitial, never a disadvantage. More accurate static 
typeinfo leads to less type tests at runtime, faster jumps (already 
explained by Francois) and better inlining, across all VMs.

> Also, how do you measure the improvement? Is it just wall clock time 
> with and without the change?

That's wallclock time with and without the change, using bnux 
deserialization, as always.

> I couldn't figure out how to get this number from the profiles you 
> sent,

Profilers just highlight were hotspots are, wallclock time tells what 
the real improvement of any change is.

> though they were quite interesting with respect to where time was 
> being spent, and did show me where to grab another ~20% improvement in 
> typical building speed, though that won't help you since you're not 
> using the Builder for these numbers.

Good :-)

> > 10% speedup for moving Attributes.ArrayList into Element, which makes 
> > access faster, plus saves a little memory
> > (keeping static accessor methods in class Attributes, and adding an 
> > "ArrayList" parameter for the attributes)
> > Element.java:
> > //    private Attributes attributes = null;
> >     private ArrayList attributes = null;
> > Semantics remain unchanged by this.
>
> This one surprises me. Why would pulling the ArrayList into Element, 
> but still using static accessor methods in another class be any 
> improvement?  Is the compiler inlining the method calls or some such?

Because there is one level less indirection for a call that uses the 
ArrayList. Instances of class "Attributes" become unnecessary. The 
static accessor methods are inlined without problem anyway.

> I tried implementing this, and in my first pass memory usage actually 
> went up by a noticeable amount, though now I think I see where my 
> mistake was, and I should be able to fix that.

To reduce memory, you need to *move* the state from Attributes into 
Element, not duplicate it. Keeping static accesor method requires the 
least amount of code changes, retains some level of modularity, 
although the accessor methods could also be moved into Element, if 
desired. See snippet at end of mail.

> > With those patches applied bnux deserialization from CVS now yields:
> > weblog.xml: 40 MB/s
> > wurfl.xml: 55 MB/s
> > factbook.xml: 82 MB/s
> > soap.xml: 30 MB/s
>
> I assume weblog.xml, factbook.xml, and soap.xml are from Sosnoski's 
> XBIS. Is that right? Where is wurfl.xml from?

There are from XBIS, right. wurfl.xml is contained in 
http://wurfl.sourceforge.net/wurfl.zip

> This is on Linux with Java 1.5, right? What sort of hardware are you 
> using for these tests?

Benchmark configuration: no ZLIB compression, xom-1.0b7, non-validating
XOM Builder using xerces-2.6.2, no DTD or schema, SUN JDK 1.5.0 server 
VM,
commodity PC 2004, Pentium 4, 2.8 GHz, Redhat 9.

All my numbers are based on that, and will continue to do so.

Here is the Attributes.java snippet:

   static Attribute get(int index, ArrayList attributes) {
        return (Attribute) attributes.get(index);
    }


    static void add(Attribute attribute, ArrayList attributes) {

        checkPrefixConflict(attribute, attributes);

        // Is there already an attribute with this local name
        // and namespace? If so, remove it.
        Attribute oldAttribute = get(attribute.getLocalName(),
          attribute.getNamespaceURI(), attributes);
        if (oldAttribute != null) remove(oldAttribute, attributes);

        attributes.add(attribute);

    }


analogous for:

    static void checkPrefixConflict(Attribute attribute, ArrayList 
attributes)
    static void remove(Attribute attribute, ArrayList attributes)
    static Attribute get(String localName, String namespaceURI, 
ArrayList attributes) {
    static ArrayList copy(ArrayList attributes) {
    }