Maintenance: Planio will be observing a scheduled maintenance window this Tuesday, November 5, 2024 from 03:00 UTC until 06:30 UTC to perform urgent network maintenance in our primary data center. Your Planio account will be unavailable during this maintenance window.
Bug #1875
closed
Performance slowdown with Saxon-CE
0%
Description
The follow Saxon-CE performance experiences have been reported by Alf Eaton in a post on the forum title 'Intent to Deprecate and Remove: XSLT'. See full discussion: https://groups.google.com/a/chromium.org/forum/#%21searchin/blink-dev/xslt$20blink/blink-dev/zIg2KC7PyH0/Ho1tm5mo7qAJ
I'm using XSLT in http://macrodocs.org/ to convert documents from XML to HTML. It doesn't have many users, but is useful as a demonstration that if different publishers make XML available in a standard format, readers can choose how they want the documents to be displayed, by altering the XSL and CSS. It all runs client-side, so there's no transformation on the server.
As people have been recommending Saxon-CE, I've added it today as an alternative XSLT processor. I found that setting it up it wasn't well documented (which is probably why I hadn't tried it before), but it was straightforward enough to include. The downsides are that a) clients have to download around 1MB of extra code (vs the 561kb of binary being removed from Blink), and b) it adds over 1 second to the transformation time that was about 40ms using Chrome's native XSLT processor.
Still, if the speed of Saxon-CE can be improved (or if there's no other option), I'd be ok with switching to using it, especially if there are security benefits: there are already differences between browser implementations of native XSLT processors, and it would be nice to have something that runs reliably cross-platform.
For comparison, http://macrodocs.org/?doi=10.7554/eLife.00003 (native) vs http://macrodocs.org/?doi=10.7554/eLife.00003&xslt=saxonce (Saxon-CE).
Alf
Updated by O'Neil Delpratt about 11 years ago
Reply added by Alex Milowski:
An interesting data point would be to track the load vs transformation time:
var start = Date.now();
/* import the XSL stylesheet */
if (data.xslt == "saxonce") {
var processor = Saxon.newXSLT20Processor(xsl);
} else {
var processor = new XSLTProcessor();
processor.importStylesheet(xsl);
}
var loaded = Date.now();
/* transform the XML document to an XHTML fragment */
var fragment = processor.transformToFragment(dom, document);
if (typeof console != "undefined") {
var end = Date.now();
console.log("XSLT processing took " + (end - start) + "ms, load "+(loaded - start)+"ms");
}
You should also be able to re-use the processor but that will not help you if you only need to do one transform.
Updated by O'Neil Delpratt about 11 years ago
Reply by Alf Eaton:
When I tried running the transformation twice in a row, the time for
the second transformation went down to around 450ms, so about half of
the time was in loading the stylesheet and half in the transformation.
That's just a single test though, so I wouldn't conclude too much
without a proper benchmark.
Updated by Michael Kay almost 7 years ago
- Status changed from New to Won't fix
Closing remaining Saxon-CE issues as "won't fix" since the product is now superseded by Saxon-JS and there is no plan to do any further maintenance.
Please register to edit this issue
.