DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20710>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20710 Performance Problems-NEED HELP! ------- Additional Comments From [EMAIL PROTECTED] 2003-07-10 21:55 ------- Andreas, in the profiling that I did the majority of the time was related to template processing. I thought of one way to reduce the number of template stack frames. This was to change "constant" starting element tags and their matching closing tags into just text. For example change: <xsl:template name="HEADER"> <xsl:variable name="XmlFilePath">copyright.xml</xsl:variable> <xsl:comment>HEADER</xsl:comment> <table width="770" border="0" cellspacing="0" cellpadding="0"> <tr> <td id="hbd" width="175"><a href="{document($XmlFilePath)/COPYRIGHT/LINK/HREF}" ... </tr> </table> Into: <xsl:template name="HEADER"> <xsl:variable name="XmlFilePath">copyright.xml</xsl:variable> <xsl:comment>HEADER</xsl:comment> <xsl:text disable-output-escaping="yes"><![CDATA[[<table width="770" border="0" cellspacing="0" cellpadding="0"> <tr> ]]></xsl:text> <td id="hbd" width="175"><a href="{document($XmlFilePath)/COPYRIGHT/LINK/HREF}" ... <xsl:text disable-output-escaping="yes"><![CDATA[[</tr> </table>]]></xsl:text> The disadvantages are: 1) You need to change your stylesheets 2) You need to very carefully match constant opening elements with closing ones 3) It is not proven to go faster. I did a test with a large constant HTML file that was put out simply as: <template match="/"> <HTML>.... lots of stuff ... </HTML> </template> It ran about 10% faster for XSLTC, but about 10 times slower for Xalan interpretive. Given time I'll return to that thought. So the main point here is that we are still looking into this performance issue, and that is the reason for this append. However my suggestion above only seems to yield worse results than before so I DO NOT suggest you try it. -------------------------------------------- I also got this note from Henry Zongaro who spent some time looking at this one. Hi Brian, I profiled Xalan-J interpretive with the test for bug 20710. I suspect there are still opportunities for improvement there. For instance, a fair chunk of time is spent in NodeTest.execute. That calls DTMDefaultBase.getNodetype, SAX2DTM.getNamespaceURI and SAX2DTM.getLocalName. All three of those methods call DTMDefaultBase._exptype and use that to index the m_expandedNameTable, which seems awfully wasteful to me. It seems like it would be a better bet to have a way to extract all three of those values from m_expandedNameTable at one go. I also see that ToHTMLStream.writeAttrURI appears pretty high on the list, but I'm not sure whether I've picked up all of your serialization changes. Did you apply the same optimizations to attributes that could be URI's as to those that aren't URI's? It might also be worth seeing whether those opportunities could be picked up by Xalan-J Interpretive as well. I think it would also be worth a look into why the performance is so bad for XSLTC. As I mentioned, it looks like it spends an inordinate amount of time in DescendantIterator.next - it might be worth comparing Xalan-J Interpretive and XSLTC to see why XSLTC spends so much more time processing descendants. Thanks, Henry
