[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Saxon .Net API performance


Subject: Re: [xsl] Saxon .Net API performance
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 01 Sep 2010 23:50:16 +0100

On 01/09/2010 5:28 PM, Merrilees, David wrote:
Thanks Andrew

Some of our XSLT is unwieldy, and upgrading to XSLT 2.0 will help us organise our code more effectively. What will really help me sell this change to the people holding our purse strings is performance improvements. Apart from grouping, what features of XSLT 2.0 can I take advantage of to improve performance?

I am acutely aware of your difficulty, having spent many years working for managers who did not understand the benefits of refactoring in software engineering (or rather, the costs of not refactoring). Frankly, there are far too many managers making engineering decisions without the engineering knowledge needed to make them. But I think that professionally, you should aim to sell it on the true benefits - reduced lifetime costs, increased longevity, greater reuse, higher quality, hgher productivity, ..., rather than trying to construct an artificial case based on performance benefits. For if performance benefits are your primary goal, refactoring may or may not be the most appropriate way to achieve them.

I once earned a day's pay by visiting a client who had a performance problem; after a quick look at their XSLT code I suggested measuring how the performance under Saxon 8.x compared with the performance of Saxon 6.5, which they had been using - thinking that this was merely to collect a bit more data. It ran about 30 times faster, and solved all their problems, so I was able to go home an hour after arriving. But unfortunately, this is the exception rather than the rule. Performance isn't one dimensional: every performance problem is different, and you can never say that product X is N% faster than product Y without reference to the task being performed - and in practice the results are highly sensitive to very small variations in the nature of the workload. For that reason, I would never embark on a performance improvement project with any set ideas about the nature of the solution. If your project is about performance improvement, then your focus should be on measurement and analysis, and upgrading components of the solution should become part of the project only when the analysis and measurement shows that it will contribute.

Michael Kay
Saxonica


Current Thread
Keywords