Project

Profile

Help

Bug #1875

closed

Performance slowdown with Saxon-CE

Added by O'Neil Delpratt about 11 years ago. Updated almost 7 years ago.

Status:
Won't fix
Priority:
Normal
Sprint/Milestone:
-
Start date:
2013-08-28
Due date:
% Done:

0%

Estimated time:
Platforms:

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

Please register to edit this issue

Also available in: Atom PDF