Re: [xml] libxml2 performance

Hi Gary, All,

Thank you for your interesting performance data. A first question which 
arises for me, is to what extent do you see the malloc cost on your 
platform? Is this a (large?) part of the other 69.5%?

Then, as I'm still struggling to get the equivalent of gmake tests
running on WIN32, I kindly ask you to test (for performance
and validity)
- removing the ctxt->token test in CUR and RAW
- dis-inline (make function calls) all but the first line of SHRINK and 

   %  cumulative    self        self    total
 time    seconds      seconds    calls  ms/call  ms/call name
  5.7        0.45    0.22  2235327    0.00    0.00  xmlCurrentChar [17]
  [13] 2.3        0.91    0.09  1039422    0.00    0.00  xmlNextChar    

For these two candidates, I'm still thinking about replacing all
UNICODE codepoint extraction and testing with a lookup based 
approach, as in [rough sketch]:

xmlChar c0 = ctx->input->cur [0];
xmlChar c1 = ctx->input->cur [1];
xmlChar c2 = ctx->input->cur [2];

int isNameChar (xmlChar c0, xmlChar c1, xmlChar c2) {
        return (table2 [c2 + table1 [c1 + table0 [c0] << 8] << 8) & 

In fact, more complicated bit shuffling may be necessary for keeping the 
lookup tables small, so it's not quite clear, whether it's worth the trouble.

If people are interested in getting involved in a libxml2 performance
improvement exercise, then contact me directly and we can start to decide
who's going to work on what and what changes make sense. 

I'm definitively interested, but being on WIN32 I feel a bit toolwise 

Also, the goal of optimization may differ to some extent. By making
gmake tests the benchmark, you try to save time for quite a range of 
applications. My primary benchmark are XML files typically produced by
object forest freezing: large number of short tags and little text. 

I don't anticipate this being a high intensity project, more like a 
marathon with low rates of change over a sustained period of time. I've
got a very conservative attitude when it comes to changing code for
performance benefits.

Very healthy attitude. But possibly not all changes are small and 
incremental. If we see mallocing and strduping a common suspect 
between platforms, a larger refactoring of parser.c, sax.c and tree.c may 
be necessary.

Peter Jacobi

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