Re: [xml] libxml2 performance

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
xml gnome org


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