This test only measures transformation time not loop time (ignoring TinyTree build)

   (you can see it in better structure code attached)


The important change begins, as you say, when build a TinyTree from StreamSource (instead from DOMSource)

   from DOM : 5399
   from StreamSource: 1589

But, isn't better than StringReader (xml in memory)

  from StringReader: 1576

And, a bit slow than xalan

  from DOM: 1142 (29% better)
  from StringReader (xalan): 1019 (36% better)


Why the time to transform one XML from memory (StringReader) and from TinyTree are equals?

The time to parse one XML from memory is inexistent!?



_____________________________________________________________________________

My intention is reduce the transformation time in web environment,

Currently I'm use a java-to-xml serializer (xstream),

generate dynamic XML (with ?xml-stylesheet? procesing-instruction) in response (CustomResponseWrapper with internal buffer) to after transform with an XSLTFilter (javax.servlet.Filter)

And trying to reduce parse time by generating dynamic-xml-structure (as DOM or Other) and attach as response attribute,

generate XML structure from Java objects (using reflection)

In both cases, as string and tinytree, the XSLT transformation times are "equal"... (this optimization not reduce any time)


Thank you

note:

   Measures under JAXP trace is used with xalan and saxon (with xalan: comment tinytree, sorry)

   Measures under TinyTree trace is used with saxon (uncomment tinytree, new sorry)


Michael Kay wrote:
Thanks. None of your tests is measuring the optimum approach, which is to build a TinyTree once (from a StreamSource) and then process it repeatedly. This would look like this:
 
Configuration conf = ((PreparedStylesheet)templates).getConfiguration();
Source tinytree = conf.buildDocument(new StreamSource(source));
for (int i = 0; i < MAX; i++) {
    Transformer transformer = templates.newTransformer();
    avg += transform(transformer, tinytree);
 }
 
This is the nearest parallel to what you are doing when you measure performance with DOM input.
 
You have one test where you are creating the Tinytree repeatedly inside the loop from a DOMSource, which is exactly what Saxon does internally if you supply a DOMSource directly. And you have one test where you create a new TinyTree each time, within the loop, which is exactly what happens internally if you supply a StreamSource (the measured cost will then be dominated by the time taken to parse the input and build the tree, which you are not measuring in your DOM path).
 
Finally, I'm not quite sure which of the paths in your code relates to which of the lines in your reported results.
 
Regards,
 
Michael Kay
Saxonica


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Jose Antonio Illescas del Olmo
Sent: 08 October 2007 10:52
To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] Where is the problem?

There's nothing better that see the source...


PD: I run the same test today and now never throw OutOfMemoryError -> I don´t understand


Michael Kay wrote:
I wonder if you could explain a bit more clearly exactly what you were measuring, and how you were measuring it?
 
The OutOfMemoryError is very strange, I've no idea what's going on here.
 
Michael Kay
Saxonica


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Jose Antonio Illescas del Olmo
Sent: 05 October 2007 18:48
To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] Where is the problem?

This is complete test: shows average in msg (each test runs 10 times)



XML size: 50KB


DOM
(from File)
DOM
(from identity transform)
StringReader
xalan (JDK 1.5.0_11-b03) 169
(*) 451
182
179
saxon 8.7.3 747
(*) 1735
636
256
saxon 8.9.9.2 692
(*) 1126
570
269
saxon 8.9.9.2 (with TinyTree)
698
(*) 1099
563
252

(*) first time


XML size: 330KB


DOM
(from File)
DOM
(from identity transform)
StringReader
xalan (JDK 1.5.0_11-b03) 1019
(*) 1400
1181
1142
saxon 8.7.3
(**)
5112
(*) 5671
4262
1580
saxon 8.9.9.2
(**)
4566
(*) 5187
3768
1589
saxon 8.9.9.2 (with TinyTree)
(**)
4594
(*) 5203
3742
1559

(*) first time
(**) OutOfMemoryError


Possibles causes of problem: parse from StringReader is better (in this case) than DOM with Saxon
  • performance of xsl:copy
  • always out the result of Transformation into StringWriter
Any Idea? my code of TinyTree is aprox to:
Transformer t = myTemplate.newTransformer();
Configuration c = ((Controller) t).getConfiguration();
Source tiny = c.buildDocument(mySource);
t.transform(tiny, new StreamResult(new StringWriter()));
PD: my app "always" use tiny XML [<60KB]


Michael Kay wrote:
Saxon performs a lot better when using its own internal tree structure than
when using a DOM. Sometimes the improvement is so big that this outweighs
the cost of parsing the XML in the first place.

I've made some improvements recently - see
http://saxonica.blogharbor.com/blog/_archives/2007/3/31/2848654.html - these
are in the Saxon 8.9.9.2 beta release announced recently on this list, and
it would be interesting to know how these affect your figures. However,
unless you have a very good reason to use the DOM with Saxon, I would still
advise against it. If you want to use the same document more than once,
create it as a Saxon TinyTree, using the method
Configuration.buildDocument(). Alternatively, the XOM interface is also very
efficient.

There are various reasons the DOM is slow with Saxon. Some improvements are
possible, but the main obstacle is that access to namespace information is
intrinsically very inefficient. XSLT processors that offer good DOM
performance tend to work only with their own implementation of the DOM, not
with third-party implementations.

Michael Kay
http://www.saxonica.com/ 


  
-----Original Message-----
From: saxon-help-bounces@lists.sourceforge.net 
[mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf 
Of Jose Antonio Illescas del Olmo
Sent: 05 October 2007 12:11
To: Mailing list for SAXON XSLT queries
Subject: [saxon] Where is the problem?

*DOM (holding in memory) vs. XML on StringReader*

The XSL used is: (cached by Templates)

    <?xml version="1.0" encoding="ISO-8859-1" ?>
    <xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform
    <http://www.w3.org/1999/XSL/Transform>" 
exclude-result-prefixes="xsl">
       <xsl:template match="@*|node()">
           <xsl:copy>
              <xsl:apply-templates select="@*|node()"/>
           </xsl:copy>
           <xsl:copy> <!-- another copy to increment measures -->
              <xsl:apply-templates select="@*|node()"/>
           </xsl:copy>
       </xsl:template>
    </xsl:stylesheet>

The output is:

    DOM(from File): 1735   -> First time is slow...
    DOM(from File): 774
    DOM(from File): 746
    DOM(from File): 744
    DOM(from File): 759
    DOM(from File): 745
    DOM(from File): 737
    DOM(from File): 741
    DOM(from File): 740
    DOM(from File): 740

    DOM(from IdentityTransform): 737
    DOM(from IdentityTransform): 734
    DOM(from IdentityTransform): 734
    DOM(from IdentityTransform): 743
    DOM(from IdentityTransform): 741
    DOM(from IdentityTransform): 742
    DOM(from IdentityTransform): 743
    DOM(from IdentityTransform): 743
    DOM(from IdentityTransform): 742
    DOM(from IdentityTransform): 741

    StringReader: 336
    StringReader: 260
    StringReader: 256
    StringReader: 247
    StringReader: 247
    StringReader: 247
    StringReader: 243
    StringReader: 244
    StringReader: 243
    StringReader: 242


Why XML on StringReader wins?

   In your book "Wrox - XSLT 2nd Edition"...

    /*Example 3: Holding Documents in Memor*y

    "This application is quite unrealistic, but the same principle of
    *keeping source documents* and stylesheets *in memory* 
can often be
    used *to achieve significant performance beneficts in a servlet
    environment.*"
    /



Wich is the optimal structure (DOM, SAX, String, JDOM,...) 
for "cached" 
XML, to reduce (or remove) the parse time (of xml) when 
transforms with XSLT?

Thank you




--------------------------------------------------------------
-----------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and 
a browser.
Download your FREE copy of Splunk now >> 
http://get.splunk.com/ _______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help
    


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help

  


------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________ saxon-help mailing list saxon-help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________ saxon-help mailing list saxon-help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saxon-help