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

[Steve Hay <steve hay uk radan com>]

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.