[Yanel-dev] XSLT only if XSL has changed

[Michael Wechner]

Dear Balz

If I understand correctly using Templates helps to prevent re-parsing of
XSLTs, also
when using include/import.

I don't have experience myself with it, but maybe we can try to improve
this somehow together

Have a nice weekend

Michael

Am 28.02.14 18:42, schrieb 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/20140301/06abf548/attachment.html>