Thanks Daniel. One suggestion is to adjust atomically the buffer size increment scheme based on the number of reallocs. The buffer keeps track of the number of reallocs and when it reaches a certain number, it switches to double size realloc scheme until it reaches another limit where it goes back to the fixed size increment scheme.
Regards. -chang -----Original Message----- From: Daniel Veillard [mailto:[email protected]] Sent: Monday, July 23, 2012 12:51 AM To: Chang Im Cc: LAUN Wolfgang; [email protected] Subject: Re: [xml] xmlNodeDump performance (Chang Im) On Mon, Jun 11, 2012 at 03:49:47PM +0000, Chang Im wrote: > 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. Yes when dumping to memory, the memory buffer must be grown progressively leading to a number of memory realloc() functions Those function can be especially slow on system with low memory or running some versions of Windows. Best is to dump directly to a file or a filedescriptor if you have one. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [email protected] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] https://mail.gnome.org/mailman/listinfo/xml
