Re: [xml] libxml2 performance

[Gary Pennington <Gary Pennington sun com>]

Bjorn Reese wrote:

> Gary Pennington wrote:
>
>  
>
> > performance. The statistics are warped by the excessive amount of
> > forking that goes on during the test (gmake forks each test as a
> > separate process, that's a lot of overhead), but several of the
> > functions listed below that relate to memory allocation, (e.g. realfree,
> > _morecore, _free_unlocked, _brk_unlocked, _malloc_unlocked). There's a
> >    
>
> If I interpret this correctly your profiling data also include the
> memory allocations of gmake. Is that correct?
It does. The profiling data was collected for all processes initiated as 
a result of "gmake tests".

>  
>
> > significant amount of work involved in file access as well, _stat
> > _lstat64 and I/O _libc_read, _libc_close, _write, _creat64.
> >    
>
> This, along with your other measurements, points to the same profiling
> data I obtained with Quantify over a year ago; namely that file access
> and document parsing consumes most of the CPU time. I don't recall
> memory allocation being amoung the most promising areas of improvement.
I'm inclined to agree with you, although it should be noted that the 
performance of memory allocators is going to vary significantly across 
platforms. The Solaris allocator is reasonably efficient. Which platform 
did you conduct your measurements on?

> File access is difficult to address, so I mainly looked at the document
> parsing (if you look at parserInternal.c, you'll notice that the xmlIs*
> functions use a mixture of if-statements, switch-statements, and table
> lookups -- significant time was spent on balancing the exact mixture).
I'll look at the file access routines as well. There may be 
possibilities to optimise I/O interactions and I have a lot of 
experience in this area.

> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml
>  

Gary