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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--