[xslt] Performance Analysis

["Marc Adkins" <madkins whitepages com>]

Title: Performance Analysis

We have been doing a performance comparison between a three year old version of the LibXML / LibXSLT libraries and the latest version released by dVeillard with patches provided by wBrack.

Older version:

Using libxml 20608, libxslt 10105 and libexslt 804
xsltproc was compiled against libxml 20608, libxslt 10105 and libexslt 804
libxslt 10105 was compiled against libxml 20608
libexslt 804 was compiled against libxml 20608

Later version:

Using libxml 20629, libxslt 10121 and libexslt 813
xsltproc was compiled against libxml 20629, libxslt 10121 and libexslt 813
libxslt 10121 was compiled against libxml 20629
libexslt 813 was compiled against libxml 20629

(plus patches, of course).

There were three tests:

• Alpha:
  Our current production templates using the older libraries.
• Bravo:
  Updated templates that run without error with the newer libraries,
  tested against the newer libraries.
• Charlie:
  Same updated templates tested against the newer libraries.

For each test we ran three 20 minute log replays against are full production system with the specified templates and libraries.  Our template base is largish.  It looks like a total of 5,362,607 characters in 892 files.  The log replays exercise a substantial percentage of those templates.

        Alpha           Bravo                   Charlie        
Avg CPU %       14.89           14.96   0.46%           15.39   3.34%  
Interrupts/s    1545.65         1552.58 0.45%           1573.41 1.80%  
Memory  1738837         1739171 0.02%           1584031 -8.90% 
IOps/s  13.81           13.98   1.26%           32.98   138.92%
Trans/s 46.19           46.41   0.47%           46.21   0.03%  

• We understand slightly more CPU.  If nothing else this corresponds to the additional error checking that we see being done.  The affect is minimal in any case.
• The memory usage drops.  I see notes in bugs for the code line about caching.  This makes sense and is a nice side effect.
• The I/O operations per second is somewhat disconcerting.  We're trying to figure out what this means.  One thing we're thinking is that perhaps the older libraries read from disk in bigger chunks so that we're seeing more smaller I/O hits than before.  However, we haven't actually nailed this down yet.  Any insight would be appreciated, though this is still well within what our hardware will handle.

Regardless, we thought that someone might be interested in our results.  We find them encouraging and we're on track to update the libraries on our production site.

Thanks to dVeillard and wBrack for all their help.

Marc M. Adkins