Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Small improvements

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] Small improvements
  • Date: Mon, 29 Nov 2004 14:06:34 -0800

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) {
}





Archive powered by MHonArc 2.6.24.

Top of Page