Improving performance of Guththila

I am doing some improvements to Guththila XML parser these days. Guththila XML parser is the default parser used by Axis2/C. The modifications to the code was very simple, but gave a huge improvement. We got about 3-4 times improvement during this exercise. Compare the performance of revision 812074 Vs 817160 for message size of 64kbytes.

I was using callgrind to profile Axis2/C. Improvements were mainly for big message processing. I used 1M messages to find the bottlenecks.

• Initially, guththila was taking 674 M clock cycles to process 3 messages
• guththila_next_char method is using many pointer references. Removing some of them by keeping variables resulted in guththila taking only 634 M clock cycles
• guththila next char was returning a character by comparing c>=0?c;-1. just returning c without the comparison resulted in 591M clock cycles
• guththila_next_char method was called for each character of the payload. However, only first five lines of the code was executed around 99% of the time. For big messages, method calling overhead was very high. (In our case, it was called 10000000 times). Moving first five lines into a macro and calling the method if the macro cannot satisfy (which is less thank 1% of the time) resulted in 389M clock cycles
• GUTHTHILA_IS_SPACE macro was checking (c == 0x20 || c == 0xD || c == 0xA || c == 0x9) and returning the result. But for majority of the cases, a character is not a space and above operation needed 4 comparisons to get a result. Replacing it with ((c < 0x21) && (c == 0x20 || c == 0xD || c == 0xA || c == 0x9)) made only one comparison for most of the cases, resulting in 289M clock cycles.
• To find next occurrence of a character, guththila_next was going character by character until we find a match. Replacing it with memchr method resulted in 59M clock cycles.

Even though the modifications are very simple, the CPU cycle needed to process three 1M messages were brought down from 674M cycles to just 59M cycles.