Re: [xml] xmlNodeDump performance (Chang Im)

Thanks for your suggestion.  Well taken and it makes sense for the entire tree dumping.
The performance could matter even with a subtree case depending upon the size.

I tried what Contrad suggested with xmlSetBufferAllocationScheme and that made a significant difference.
For the entire tree, the time taken is reduce from 68 seconds to .67 seconds.


-----Original Message-----
From: xml-bounces gnome org [mailto:xml-bounces gnome org] On Behalf Of LAUN Wolfgang
Sent: Monday, June 11, 2012 2:50 AM
To: xml gnome org
Subject: Re: [xml] xmlNodeDump performance (Chang Im)

Message: 1
Date: Fri, 8 Jun 2012 01:25:30 +0000
From: Chang Im <Chang IM watchguard com>
To: "xml gnome org" <xml gnome org>
Subject: [xml] xmlNodeDump performance
Message-ID: <3A3B5E9AABD6A64AB5AE8DAAC1985D0504C7AD1E MBX1 wgti net>
Content-Type: text/plain; charset="us-ascii"


I am new to libxml and XML itself.  We are using version 2.7.7.

I am looking into performance issue related to xmlNodeDump of entire tree.
The size of XML file is about 20 MB and it takes about 60+ seconds with xmlNodeDump.

Do you really need this tree dump in memory? If the ultimate goal is to have this on a file, the functions in 
xmlsave (xmlSaveToFd, xmlSaveToFilename,...) should be preferred.

Oprofiling showed memcpy as the hit.

The xmlBufferResize takes MINLEN increments and that is defined as 
4000 in xmlIO.c When MINLEN is changed to 400,000 to see the effect, the time taken is changed to about 1 
sec from 60+ seconds.

When MINLEN is changed to 40000, time taken is changed to 7 seconds.

Is this something needs to be tuned properly to support large XML files?
If so, any good suggestions?

Chang Im | Software Engineer
WatchGuard Technologies, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]