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

[Daniel Veillard <veillard redhat com>]

On Tue, Jul 13, 2004 at 09:58:33AM -0400, Daniel Veillard wrote:
> > Attached is a bzip2 of the output running my test program with just 
> > encoding="utf-8".  There is a sequence of Realloced() lines in which the 
> > buffer is being doubled:
> >
> > Realloced(100 to 200) Ok
> > Realloced(200 to 400) Ok
> > Realloced(400 to 800) Ok
> > Realloced(800 to 1600) Ok
> > Realloced(1600 to 3200) Ok
> > Realloced(3200 to 6400) Ok
> > Realloced(6400 to 12800) Ok
> > Realloced(12800 to 25600) Ok
> > Realloced(25600 to 51200) Ok
> > Realloced(51200 to 102400) Ok
> > Realloced(102400 to 204800) Ok
> > Realloced(204800 to 409600) Ok
> > Realloced(409600 to 819200) Ok
> > Realloced(819200 to 1638400) Ok
> > Realloced(1638400 to 3276800) Ok
> > Realloced(3276800 to 6553600) Ok
> > Realloced(6553600 to 13107200) Ok
> >
> > but then a very long sequence in which this doesn't happen:
> >
> > Realloced(4002 to 32208) Ok
> > Realloced(32208 to 48154) Ok
> > Realloced(48154 to 64154) Ok
> > Realloced(64154 to 80154) Ok
> > Realloced(80154 to 96154) Ok
> > Realloced(96154 to 112154) Ok
> > Realloced(112154 to 128154) Ok
> > Realloced(128154 to 144154) Ok
> > Realloced(144154 to 160154) Ok
> > ...
> >
> > So is that likely to be the cause of the problem?
>
>   yes definitely. There is something wrong w.r.t. buffer allocation
> in conjunction with saving to a file descriptor. It should never need
> a buffer of the size of teh output document, this should be streamed out
> and works on unices...

  Hum, scratch that. Since you're saving to memory a 10MB document,
then this allocation/reallocation is normal.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/