GNOME Bugzilla – Bug 146697
xmlDocDumpMemory() is VERY slow on Win32
Last modified: 2009-08-15 18:40:50 UTC
In the course of tracing a memory leak using libxml2 via its Perl interface, XML-LibXML, I stumbled across the fact that xmlDocDumpMemory() runs incredibly slowly on Win32 compared to Linux. The Perl memory leak involved repeatedly parsing and then dumping in memory a set of 4 particular XML files. The following C program, using libxml2 directly, does essentially the same thing: #include <stdio.h> #include <time.h> #include <libxml/parser.h> #include <libxml/tree.h> int main(void) { xmlDocPtr doc; xmlChar *result = NULL; int i, len = 0; char *files[] = { "4M UNIBODY FODEN 4000WB.drg", "IVECO 130E18K 3M UNIBODY (3).drg", "IVECO 130E18K 13T MULTISPREAD.drg", "IVECO 340E38H-TRANSVERSE+2x3 HOTBOX.drg" }; time_t start, end; while (1) { time(&start); for (i = 0; i < 4 ; i++) { if ((doc = xmlReadFile(files[i], NULL, 0)) != NULL) { printf("%d - OK\n", i); } else { printf("%d - NOT OK\n", i); } xmlDocDumpMemory(doc, &result, &len); if (result != NULL) { printf("%d - OK\n", i); xmlFree(result); } else { printf("%d - NOT OK\n", i); } xmlFreeDoc(doc); } time(&end); printf("Took %d seconds\n", end - start); } } When I ran this program I found that there does not appear to be any memory leak, but each time around the while() loop takes about 24 seconds. Petr Pajas, looking into the Perl memory leak for me, tried the above program on his Linux machine and found it takes only 1 second each time around the while() loop. If I remove this section from the program: xmlDocDumpMemory(doc, &result, &len); if (result != NULL) { printf("%d - OK\n", i); xmlFree(result); } else { printf("%d - NOT OK\n", i); } then my times drop to about 1 second. On the Linux machine, the program only became very slightly quicker. Thus, it appears that xmlDocDumpMemory() runs very slowly on Win32. Whether or not this is related to the memory leak in the Perl code on Win32 (which couldn't be reproduced on Linux, btw) is hard to say, but it would make a huge difference to my real software if the slowness of xmlDocDumpMemory() on Win32 could be rectified. Here is a link to the thread discussing the Perl interface memory leak, if you are interested: http://marc.theaimsgroup.com/?t=108928189600002&r=1&w=2 If you want the actual 4 XML files that these results were produced with, they are available on an FTP site. Please e-mail me for login credentials.
I don't have access to a Windows environment, and as far as I can tell it's not free to install and use them. Nearly impossible for me to guess what's going on. There is known issues about memory allocators on windows when library code is compiled one way and application is compiled differently (compiler or even compiling options). Usually it crashes when freeing the document, YMMV ... Other potential issues might be a defect in the buffer allocation strategy (not doubling and hence copying all the time block is reallocated). C code without input, without information about compilers and options won't allow people to reproduce it. I won't , you should at least use a profiler on your OS to see what's going on. I put back priorities as normal. From a GNOME project POV the bug is actually NOTGNOME, but I don't want to close it arbitrarilly. Using the libxml2 list is a far better idea if you want to get in touch with Windows users, see http://xmlsoft.org/bugs.html Daniel
Just so we don't lose track, mailing list thread on this is here: http://mail.gnome.org/archives/xml/2004-July/msg00070.html
That link should be http://mail.gnome.org/archives/xml/2004-July/msg00071.html I implemented the patch for Windows buffer re-allocation suggested. Fixed code is in CVS.
This should be fixed in release libxml2-2.6.12. thanks, Daniel