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

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 Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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