OpenLaszlo Performance Tip: Attributes, Not Nodes

OpenLaszlo applications typically access numerous web services that respond with XML. That XML must be loaded over HTTP. Many developers overlook the effect that the format of the XML in those services can have on the performance of an application.

Most XML guides suggest that an ideal XML format should look something like this:

<contact>

    <id>0</id>

    <city>Bedrock</city>

    <zip>90210</zip>

    <firstname>Fred</firstname>

    <lastname>Flintstone</lastname>

    <phone>415-555-0999</phone>

    <state>CA</state>

    <address>1234 Stone Lane</address>

    <country>USA</country>

    <email>fred@example.com</email>

</contact>

Note how each property of the contact is represented by an XML node, with a text node inside, representing the value of that property. That may be very readable to humans, but it wreaks hell on rich Internet applications (RIAs). Note that I said RIAs, not just OpenLaszlo applications. As you’ll see, this tip holds true for various platforms, including OpenLaszlo, Flex and DHTML. When that data is parsed by the client – it needs to be parsed, so the data can be accessed easily – the XML parser has to create a separate runtime object for each of those subnodes. In OpenLaszlo, that class is lz.DataElement. So our contact above cost us 11 nodes. No wait – it actually cost us 21 nodes. Remember that each text node is treated as a separate object too.

What we’re dealing with is not so much data loading, but data initialization. Loading the above contact isn’t going to take much time at all, but loading an address book with 500 contacts formatted as above will. With 500 contacts, the application will be initializing 5,500 nodes (i.e. 11 * 500). The effect this will have for the user is a noticeable delay after the web service is loaded. The application will consume a lot of CPU and feel sluggish (probably unusable) while the data is being parsed.

Happily, there’s an easy fix. Simply reformat your data to rely on attributes for property values where practical. The above contact would therefore look like this:

<contact id="0"

         city="Bedrock"

         zip="90210"

         firstname="Fred"

         lastname="Flintstone"

         phone="415-555-0999"

         state="CA"

         address="1234

         Stone

         Lane"

         country="USA"

         email="fred@example.com"/>

How much of an improvement could you reasonably expect? It turns out quite a lot, actually. I tested data initialization time on the following platforms:

• OpenLaszlo 4.2 nightly compiled to SWF8
• OpenLaszlo 4.2 nightly compiled to DHTML in Firefox 3
• OpenLaszlo 4.2 nightly compiled to SWF9
• Flex 3 (using e4x data, since it’s the closest way of handling XML to OpenLaszlo’s)
• DHTML in Firefox 3 (using the Dojo toolkit and parsing the returned XML with dojox.xml.xmlParser, since the default XML objects don’t have the type of functionality that OpenLaszlo’s or Flex’s do)
• DHTML in Internet Explorer 6 (same platform options as for Firefox 3.

I compared how long it took to load and initalize a locally-served (over HTTP) XML document that contained 500 contacts with data saved as nodes, versus one that contained 500 contacts with data saved as node attributes.

As you can see, using attributes instead of nodes for your XML data is significantly faster when dealing with larger datasets.

I should mention that I’ve been looking forward to trying out the new OpenLaszlo SWF9 runtime, and am pleased to see that it’s so much faster. The SWF9 runtime is present in OpenLaszlo 4.1, but a number of things are broken – datasets don’t work, for example. The 4.2.x nightly build from last night is the first build to have working datasets (hence I was able to run my test).

You can download my sample data and LZX, MXML and HTML files for the various runtimes here.