GNOME Bugzilla – Bug 434806
write to disk compiled xslt to address 1 time processing of large stylesheets
Last modified: 2021-07-05 11:00:26 UTC
With large stylesheets (174k all up) there is significant overhead in actually importing the stylesheet i.e $xsltprocessor->importStylesheet( $xsldom ); which i believe calls the function xsltParseStylesheet in xslt.c This is not an issue if you are processing the stylesheet multiple times, however if you are doing only a single process per "build" of the xslt it's not very efficient. For example PHP5 uses libxml and libxslt and works on a per request basis. This means that for each request, it builds the xsltprocessor, processes the xml and spits out the resulting xml. With the above sized stylesheet,a large portion of the request time ( more significant than connection to a postgresql database) is spent importing/parsing the stylesheet and the requests/second tend to degrade fairly rapidly. If possible, I think it would be great if libxsl had the facility to write to disk, a pre-parsed xslt and was able to then use it in subsequent calls to libxslt. I realise that this is probably platform specific, ie a template cached to disk on an i386 platform probably won't be readable on another arch. I can't see that it would be a major issue for those who would benifit from this ability. The main benefit is for people that have say low traffic 600+ websites hosted on a machine. There is not much point having all those xslt's cached in memory, and idle if they aren't being used the majority of the time. It is still nice for visitors to have a responsive, low latency website when they do visit.
If you have all your stylesheets available locally compiling the XSLT should be near instantaneous. Check why it takes so long, that should not hapen. If you are processing the stylesheet multiple times, you should reuse the compiled stylesheet, that's possible at the C API level, if PHP does not allow it ask them to fix it or explain how to do this but this is not the appropriate place to request it. Now to save to a non-standard format locally, it's out of the question, I don't intend to do this, It would be nearly as comnplex as writing yet another parser. Instead find out why loading your XSLT takes so long for example with a profiling tool on xsltproc yourstysheet. Sorry there is enough work to do to follow standards that there is zero chance I would work on an area not standardized. Daniel
Andrew, you can do e.g. xmllint --nonet --c14n --xinclude input.xsl | sed -ne '/<!--/ { :c; /-->/! { N; b c; }; /-->/s/<!--.*-->//g }; /^ *$/!p;' | sed '/^$/d' >output.xsl This does all xincludes, c14n and strips comments. Unfortunately the savings are maginally. Please reopen this bug if needed (I mark it as FIXED/NOTGNOME as its already possible to some extend).
Andrew, if you ask for <xsl:import> and <xsl:include> to be resolved and the resulting xsl to be written to disk, I am trying that but so far go *zero* support for xslt developers (if any left). I am reopening the bug for that case.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxslt/-/issues/ Thank you for your understanding and your help.