After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 146697 - xmlDocDumpMemory() is VERY slow on Win32
xmlDocDumpMemory() is VERY slow on Win32
Status: VERIFIED FIXED
Product: libxml2
Classification: Platform
Component: general
2.6.10
Other Windows
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2004-07-09 08:59 UTC by Steve Hay
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steve Hay 2004-07-09 08:59:43 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.
Comment 1 Daniel Veillard 2004-07-09 09:42:12 UTC
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
Comment 2 John Fleck 2004-07-10 12:37:48 UTC
Just so we don't lose track, mailing list thread on this is here:

http://mail.gnome.org/archives/xml/2004-July/msg00070.html
Comment 3 William M. Brack 2004-07-26 18:02:08 UTC
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.
Comment 4 Daniel Veillard 2004-08-22 20:35:45 UTC
 This should be fixed in release libxml2-2.6.12.
                                                                                
   thanks,
                                                                                
Daniel