DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Observability Architecture: Financial Payments Introduction
  • Getting Started With Istio in AWS EKS for Multicluster Setup
  • Five Java Books Beginners and Professionals Should Read
  • Introduction to Domain-Driven Design

Trending

  • Observability Architecture: Financial Payments Introduction
  • Getting Started With Istio in AWS EKS for Multicluster Setup
  • Five Java Books Beginners and Professionals Should Read
  • Introduction to Domain-Driven Design
  1. DZone
  2. Coding
  3. Languages
  4. JAXB, SAX, DOM Performance

JAXB, SAX, DOM Performance

Alex Staveley user avatar by
Alex Staveley
·
Dec. 31, 11 · Interview
Like (4)
Save
Tweet
Share
44.05K Views

Join the DZone community and get the full member experience.

Join For Free

 This post investigates the performance of unmarshalling an XML document to Java objects using a number of different approaches. The XML document is very simple. It contains a collection of Person entities. 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<persons>
    <person>
        <id>person0</id>
        <name>name0</name>
    </person>
    <person>
         <id>person1</id>
         <name>name1</name>
    </person>
...


There is a corresponding Person Java object for the Person entity in the XML

...

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "id",
    "name"
})
public class Person {
    private String id;
    private String name;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String value) {
        this.name = value;
    }
}


and a PersonList object to represent a collection of Persons. 

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "persons")
public class PersonList {
    @XmlElement(name="person")
    private List<person> personList = new ArrayList<person>();

    public List<person> getPersons() {
        return personList;
    }

    public void setPersons(List<person> persons) {
        this.personList = persons;
    }
}


The approaches investigated were:

  • Various flavours of JAXB
  • SAX
  • DOM

In all cases, the objective was to get the entities in the XML document to the corresponding Java objects. The JAXB annotations on the Person and PersonList POJOS are used in the JAXB tests. The same classes can be used in SAX and DOM tests (the annotations will just be ignored). Initially the reference

implementations for JAXB, SAX and DOM were used. The Woodstox STAX parsing was then used. This would have been called in some of the JAXB unmarshalling tests.


The tests were carried out on my Dell Laptop, a Pentium Dual-Core CPU, 2.1 GHz running Windows 7.


Test 1 - Using JAXB to unmarshall a Java File.


@Test
public void testUnMarshallUsingJAXB() throws Exception {
    JAXBContext jc = JAXBContext.newInstance(PersonList.class);
    Unmarshaller unmarshaller = jc.createUnmarshaller();
    PersonList obj = (PersonList)unmarshaller.unmarshal(new File(filename));
}


Test 1 illustrates how simple the progamming model for JAXB is. It is very easy to go from an XML file to Java objects. There is no need to get involved with the nitty gritty details of marshalling and parsing.


Test 2 - Using JAXB to unmarshall a Streamsource


Test 2 is similar Test 1, except this time a Streamsource object wraps around a File object. The Streamsource object gives a hint to the JAXB implementation to stream the file.

@Test
public void testUnMarshallUsingJAXBStreamSource() throws Exception {
    JAXBContext jc = JAXBContext.newInstance(PersonList.class);
    Unmarshaller unmarshaller = jc.createUnmarshaller();
    StreamSource source = new StreamSource(new File(filename));
    PersonList obj = (PersonList)unmarshaller.unmarshal(source);
}



Test 3 - Using JAXB to unmarshall a StAX XMLStreamReader


Again similar to Test 1, except this time an XMLStreamReader instance wraps a FileReader instance which is unmarshalled by JAXB.

@Test
public void testUnMarshallingWithStAX() throws Exception {
    FileReader fr = new FileReader(filename);
    JAXBContext jc = JAXBContext.newInstance(PersonList.class);
    Unmarshaller unmarshaller = jc.createUnmarshaller();
    XMLInputFactory xmlif = XMLInputFactory.newInstance();
    XMLStreamReader xmler = xmlif.createXMLStreamReader(fr);
    PersonList obj = (PersonList)unmarshaller.unmarshal(xmler);
}



Test 4 - Just use DOM

This test uses no JAXB and instead just uses the JAXP DOM approach. This means straight away more code is required than any JAXB approach.

@Test
public void testParsingWithDom() throws Exception {
    DocumentBuilderFactory domFactory = DocumentBuilderFactory.newInstance();
    DocumentBuilder builder = domFactory.newDocumentBuilder();
    Document doc = builder.parse(filename);
    List personsAsList = new ArrayList();
    NodeList persons = doc.getElementsByTagName("person");
    for (int i = 0; i <persons.getLength(); i++) {
        Element person = (Element)persons.item(i);
        NodeList children = (NodeList)person.getChildNodes();        Person newperson = new Person();
        for (int j = 0; j < children.getLength(); j++) {
            Node child = children.item(j);
            if (child.getNodeName().equalsIgnoreCase("id")) {
                newperson.setId(child.getNodeValue());
            } else if (child.getNodeName().equalsIgnoreCase("name")) {
                newperson.setName(child.getNodeValue());
            }
        }        personsAsList.add(newperson);
    }
}

Test 5 - Just use SAXTest 5 uses no JAXB and uses SAX to parse the XML document. The SAX approach involves more code and more complexity than any JAXB approach. The Developer has to get involved with the parsing of the document.

@Test
public void testParsingWithSAX() throws Exception {
    SAXParserFactory factory = SAXParserFactory.newInstance();
    SAXParser saxParser = factory.newSAXParser();
    final List<person> persons = new ArrayList<person>();
    DefaultHandler handler = new DefaultHandler() {
        boolean bpersonId = false;
        boolean bpersonName = false;
        public void startElement(String uri, String localName,String qName,    Attributes attributes) throws SAXException {
     if (qName.equalsIgnoreCase("id")) {
                bpersonId = true;
                Person person = new Person();
                persons.add(person);
            } else if (qName.equalsIgnoreCase("name")) {
                bpersonName = true;
            }
        }
        public void endElement(String uri, String localName, String qName) throws SAXException {
        }
        public void characters(char ch[], int start, int length) throws SAXException {
     if (bpersonId) {
                String personID = new String(ch, start, length);
                bpersonId = false;
                Person person = persons.get(persons.size() - 1);
                person.setId(personID);
            } else if (bpersonName) {
                String name = new String(ch, start, length);
                bpersonName = false;
                Person person = persons.get(persons.size() - 1);
                person.setName(name);
            }
        }
    };
    saxParser.parse(filename, handler);
}



The tests were run 5 times for 3 files which contain a collection of Person entities. The first first file contained 100 Person entities and was 5K in size. The second contained 10,000 entities and was 500K in size and the third contained 250,000 Person entities and was 15 Meg in size. In no cases was any XSD used, or any validations performed. The results are given in result tables where the times for the different runs are comma separated.


TEST RESULTS

The tests were first run using JDK 1.6.26, 32 bit and the reference implementation for SAX, DOM and JAXB shipped with JDK was used.


Unmarshall Type100 Persons time (ms)10K Persons time (ms) 250K Persons time (ms)
JAXB (Default) 48,13, 5,4,478, 52, 47,50,501522, 1457, 1353, 1308,1317
JAXB(Streamsource)11, 6, 3,3,244, 44, 48,45,431191, 1364, 1144, 1142, 1136
JAXB (StAX)18, 2,1,1,1111, 136, 89,91,922693, 3058, 2495, 2472, 2481
DOM16, 2, 2,2,289,50, 55,53,501992, 2198, 1845, 1776, 1773
SAX4, 2, 1,1,129, 34, 23,26,26704, 669, 605, 589,591

JDK 1.6.26 Test comments

  1. The first time unmarshalling happens is usually the longest.
  2. The memory usage for the JAXB and SAX is similar. It is about 2 Meg for the file with 10,000 persons and 36 - 38 Meg file with 250,000.  DOM Memory usage is far higher.  For the 10,000 persons file it is 6 Meg, for the 250,000 person file it is greater than 130 Meg. 
  3. The performance times for pure SAX are better. Particularly, for very large files.

The exact same tests were run again, using the same JDK (1.6.26) but this time the Woodstox implementation of StAX parsing was used.



Unmarshall Type100 Persons time (ms)10K Persons time (ms) 250K Persons time (ms)
JAXB (Default) 48,13, 5,4,478, 52, 47,50,501522, 1457, 1353, 1308,1317
JAXB(Streamsource)11, 6, 3,3,244, 44, 48,45,431191, 1364, 1144, 1142, 1136
JAXB (StAX)18, 2,1,1,1111, 136, 89,91,922693, 3058, 2495, 2472, 2481
DOM16, 2, 2,2,289,50, 55,53,501992, 2198, 1845, 1776, 1773
SAX4, 2, 1,1,129, 34, 23,26,26704, 669, 605, 589,591

JDK 1.6.26 + Woodstox test comments

  1. Again, the first time unmarshalling happens is usually proportionally longer.
  2. Again, memory usage for SAX and JAXB is very similar. Both are far better
    than DOM.  The results are very similar to Test 1.
  3. The JAXB (StAX) approach time has improved considerably. This is due to the
    Woodstox implementation of StAX parsing being used.
  4. The performance times for pure SAX are still the best. Particularly
    for large files.

The the exact same tests were run again, but this time I used JDK 1.7.02 and the Woodstox implementation of StAX parsing.


Unmarshall Type100 Persons time (ms)10,000 Persons time (ms) 250,000 Persons time (ms)
JAXB (Default) 165,5, 3, 3,5611,23, 24, 46, 28578, 539, 511, 511, 519
JAXB(Streamsource)13,4, 3, 4, 343,24, 21, 26, 22678, 520, 509, 504, 627
JAXB (StAX)21,1,0, 0, 0300,69, 20, 16, 16637, 487, 422, 435, 458
DOM22,2,2,2,2420,25, 24, 23, 241304, 807, 867, 747, 1189
SAX7,2,2,1,1169,15, 15, 19, 14366, 364, 363, 360, 358

JDK 7 + Woodstox test comments:

  1.  The performance times for JDK 7 overall are much better.   There are some anomolies - the first time the  100 persons and the 10,000 person file is parsed.
  2. The memory usage is slightly higher.  For SAX and JAXB it is 2 - 4 Meg for the 10,000 persons file and 45 - 49 Meg for the 250,000 persons file.  For DOM it is higher again.  5 - 7.5 Meg for the 10,000 person file and 136 - 143 Meg for the 250,000 persons file.

Note: W.R.T. all tests

  1. No memory analysis was done for the 100 persons file. The memory usage was just too small and so it would have pointless information.
  2. The first time to initialise a JAXB context can take up to 0.5 seconds. This was not included in the test results as it only took this time the very first time. After that the JVM initialises context very quickly (consistly < 5ms). If you notice this behaviour with whatever JAXB implementation you are using, consider initialising at start up.
  3. These tests are a very simple XML file. In reality there would be more object types and more complex XML. However, these tests should still provide a guidance.

Conclusions:

  1. The peformance times for pure SAX are slightly better than JAXB but only for very large files. Unless you are using very large files the performance differences are not worth worrying about. The progamming model advantages of JAXB win out over the complexitiy of the SAX programming model.  Don't forget JAXB also provides random accses like DOM does. SAX does not provide this.
  2. Performance times look a lot better with Woodstox, if JAXB / StAX is being used.
  3. Performance times with 64 bit JDK 7 look a lot better. Memory usuage looks slightly higher.

From http://dublintech.blogspot.com/2011/12/jaxb-sax-dom-performance.html

Testing Java (programming language) code style Java Development Kit Object (computer science) XML

Opinions expressed by DZone contributors are their own.

Trending

  • Observability Architecture: Financial Payments Introduction
  • Getting Started With Istio in AWS EKS for Multicluster Setup
  • Five Java Books Beginners and Professionals Should Read
  • Introduction to Domain-Driven Design

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: