<div dir="ltr">Thanks Michael,<div>yes I was exactly having that section of code in mind in the BasicXMLResource.java:</div><div><br></div><div>xsltHandlers[i] = tf.newTransformerHandler(uriResolver.resolve(xsltPath, xsltPath));<br>

</div><div><br></div><div>As far as I understand, this is not yet the transformation itself, it is the building of the transformer object.</div><div>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.</div>
<div><br></div><div>So I think too many includes will slow down overall performance of the XSLT.</div><div><br></div><div>Cheers, Bas</div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Fri, Feb 28, 2014 at 10:31 AM, Michael Wechner <span dir="ltr"><<a href="mailto:michael.wechner@wyona.com" target="_blank">michael.wechner@wyona.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hi Balz<br>
      <br>
      Please see my comments inline below<br>
      <br>
      Am 28.02.14 10:08, schrieb basZero:<br>
    </div><div>
    <blockquote type="cite">
      <pre>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.</pre>
    </blockquote>
    <br></div>
    At the moment we use<br>
    <br>
    <dependency groupId="xalan" artifactId="xalan"
    version="2.7.0"/><br>
    <br>
    but I am not sure whether what you are asking has actually anything
    to do with Xalan itself, but<br>
    rather how we instantiate the XSLTs inside<br>
    <br>
    <br>
    src/impl/java/org/wyona/yanel/impl/resources/BasicXMLResource.java<br>
    <br>
    It seems to me that we would have to introduce so called Templates
    as described in<br>
    <br>
<a href="http://www.javaworld.com/article/2073394/java-xml/transparently-cache-xsl-transformations-with-jaxp.html" target="_blank">http://www.javaworld.com/article/2073394/java-xml/transparently-cache-xsl-transformations-with-jaxp.html</a><br>


    <br>
    Maybe you can give it a try.<br>
    <br>
    Independent of the caching the following performance hints might
    also improve your situation<br>
    <br>
    <a href="https://xalan.apache.org/old/xalan-j/faq.html#faq-N10175" target="_blank">https://xalan.apache.org/old/xalan-j/faq.html#faq-N10175</a><br>
    <br>
    HTH<span><font color="#888888"><br>
    <br>
    Michael</font></span><div><br>
    <blockquote type="cite">
      <pre>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

</pre>
      <br>
      <fieldset></fieldset>
      <br>
    </blockquote>
    <br>
  </div></div>

<br>--<br>
Yanel-development mailing list <a href="mailto:Yanel-development@wyona.com" target="_blank">Yanel-development@wyona.com</a><br>
<a href="http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development" target="_blank">http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development</a><br></blockquote></div><br></div></div>