Re: [xml] libxml2 performance

["Peter Jacobi" <pj walter-graphtek com>]

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 
GROW

>    %  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) & 
bitNameChar;
}

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

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.

Regards,
Peter Jacobi