Re: [xml] libxml2 performance

[Bjorn Reese <breese mail1 stofanet dk>]

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?

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

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