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

[Steve Hay <steve hay uk radan com>]

Igor Zlatkovic wrote:

> On Mon, Jul 12, 2004 at 02:35:46PM +0100, Steve Hay wrote:
>  
>
> > [...]
> > generates these bizarre results for me on Win32:
> >
> > encoding="iso-8859-1": 15 seconds
> > encoding="utf-8": 15 seconds
> > : 0 seconds
> >
> > Why is xmlDocDumpMemory() so much slower when an encoding is declared?
> >
> > This is using libxml2-2.6.11 built with MSVC++ 6.0 the same way as 
> > described in my original posting.
> >
> > What results does the program produce on Linux?
> >    
>
> On this low-end machine, 2xPII @ 350MHz, all three output lines count 1 
> second.
And somebody else on Linux has reported times of 0 seconds for all three 
configurations, so it definitely looks like a Win32-specific problem.

> > Does this help anyone help me with this problem?
> >    
>
> I don't know. I'm stuck on Linux at the moment, can't boot Windows until
> tomorrow. Glancing at the libxml code, one thing I can say for sure. The
> bottleneck is either in xmlCharEncOutFunc in encoding.c, or farther down 
> the road in the UTF8toisolat and UTF8toUTF8.
>
> If you use VC6, you can compile a profile-enabled libxml and see where it
> spends most of its time. Somehow I have a bad feeling that this is a problem
> in Windows memory manager and won't be fixed easily.
I am using VC6, but I don't have any profiling software available.  I'll 
try sticking some printf() calls in around the functions that you 
mentioned and see if I can find the bottleneck.

- 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.