[Yanel-dev] XSLT only if XSL has changed

[basZero]

Thanks Michael,
yes I was exactly having that section of code in mind in the
BasicXMLResource.java:

xsltHandlers[i] = tf.newTransformerHandler(uriResolver.resolve(xsltPath,
xsltPath));

As far as I understand, this is not yet the transformation itself, it is
the building of the transformer object.
I measured a bit today and realized that for each include / import
statement, it fully parses the included file again, even if it has already
been parsed in that cycle.

So I think too many includes will slow down overall performance of the XSLT.

Cheers, Bas


On Fri, Feb 28, 2014 at 10:31 AM, Michael Wechner <michael.wechner at wyona.com
> wrote:

>  Hi Balz
>
> Please see my comments inline below
>
> Am 28.02.14 10:08, schrieb basZero:
>
> Hi,
>
> as you know, Yanel performs the XSLT (Transformation of XSL to temporary
> Java Class) for EACH request.
>
> I would like to ask, whether there is anybody out there who has played with
> these two alternative approaches:
>
> 1) extend XSLT Processor in a way, that it keeps a list of XSLs including
> timestamps and only does the transformation, if the XSL has changed. Hence:
> reuse the java classes from earlier if nothing changed.
>
>
> At the moment we use
>
> <dependency groupId="xalan" artifactId="xalan" version="2.7.0"/>
>
> but I am not sure whether what you are asking has actually anything to do
> with Xalan itself, but
> rather how we instantiate the XSLTs inside
>
>
> src/impl/java/org/wyona/yanel/impl/resources/BasicXMLResource.java
>
> It seems to me that we would have to introduce so called Templates as
> described in
>
>
> http://www.javaworld.com/article/2073394/java-xml/transparently-cache-xsl-transformations-with-jaxp.html
>
> Maybe you can give it a try.
>
> Independent of the caching the following performance hints might also
> improve your situation
>
> https://xalan.apache.org/old/xalan-j/faq.html#faq-N10175
>
> HTH
>
> Michael
>
>  This option would still have the advantage that you can change/patch XSL
> files in the running system and see the changes immediately.
>
> 2) There is an official XSLT processor mode called "cached". In this mode,
> the XSLT processor only performs the XSLT once and keeps the generated java
> classes for the lifetime of the JVM. This is certainly the fastest way of
> having XSLT in a system, but any changes to XSLs are of course ignored once
> the XSLT has happened. So this is a disadvantage.
>
> I would be interested in some hands-on experience for option 1).
>
> Cheers, Bas
>
>
>
>
>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20140228/06ed6562/attachment.html>