Re: [PATCH] Re: [xml] xmlDocDumpMemory() is VERY slow on Win32

So is this patch any good or not?

It makes a big difference on Win32, so obviously I would like to see it 
or something else with a similar performance gain applied.

Steve Hay wrote:

Daniel Veillard wrote:


On Tue, Jul 13, 2004 at 04:14:34PM +0100, Steve Hay wrote:


My soul is indeed lost :(  Where do I go from here?  (Don't say Linux...)


We need to make sure the buffer which is expanded in 16000 increment
is instead using a doubling allocation scheme like the one used for
reading it, that should solve it. One solution is to change the Grow
operation to always double (at least) if buf-alloc is XML_BUFFER_ALLOC_DOUBLEIT
in xmlBufferGrow(). Could be a 3 line patch, possibly conditionalized
with #ifdef WIN32 /* Windows realloc() is really bad */ #else #endif


With this patch (against 2.6.11 again):

*** tree.c.orig    Mon May 17 04:24:52 2004
--- tree.c    Tue Jul 13 17:18:46 2004
*** 6607,6613 ****
--- 6607,6618 ----
     if (buf->alloc == XML_BUFFER_ALLOC_IMMUTABLE) return(0);
     if (len + buf->use < buf->size) return(0);

+     /* Double buffer (if that's enough) on Win32 -- realloc() is very 
bad */
+ #ifdef WIN32
+     size = buf->size > len ? buf->size * 2 : buf->use + len + 100;
+ #else
     size = buf->use + len + 100;
+ #endif

     newbuf = (xmlChar *) xmlRealloc(buf->content, size);
     if (newbuf == NULL) {
End of Patch.

I now get the following sequence of realloc()s instead of the long 
sequence of 16000-byte increments:

Realloced(4002 to 32208) Ok
Realloced(32208 to 64416) Ok
Realloced(64416 to 128832) Ok
Realloced(128832 to 257664) Ok
Realloced(257664 to 515328) Ok
Realloced(515328 to 1030656) Ok
Realloced(1030656 to 2061312) Ok
Realloced(2061312 to 4122624) Ok
Realloced(4122624 to 8245248) Ok
Realloced(8245248 to 16490496) Ok

and the two cases with encoding declarations now run in ~0 seconds, just 
like the case without an encoding declaration :)

I tried using "if (buf->alloc == XML_BUFFER_ALLOC_DOUBLEIT ..." but it 
didn't seem to be "true".  Does it need to be set somewhere?

- Steve

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for 
the addressee(s) only.  If you have received this message in error or there are any problems, please notify 
the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not 
necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and 
any attached files for viruses: Radan Computational will accept no liability for any damage caused by any 
virus transmitted by this email.

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