Re: [xml] libxml2 performance

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

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