Re: [xml] xmlNodeDump performance (Chang Im)

[Chang Im <Chang IM watchguard com>]

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.

Regards.
-chang

-----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"
>
> Hi,
>
> 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.
-W


> 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?
>
> Thanks.
> Chang Im | Software Engineer
> WatchGuard Technologies, Inc.
>