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=22266>. 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=22266 Keep template text together with mappedfile="true" ------- Additional Comments From [EMAIL PROTECTED] 2003-08-13 02:09 ------- Unfortunately I've thrown out the actual numbers I got in the performance testing I did (all on a 1 GHz Windows XP laptop), but the salient results were as follows: 1) The patch made Tomcat faster at compiling and serving pages with a preponderance of HTML tags versus JSP tags (the lookahead does take some extra time, but is more than made up if the lookahead results in one less node to be traversed later). With the patch in place, Tomcat compiled and served index.html from the jsp-examples webapp (renamed to index.jsp, obviously) about 9% faster than without the patch. 2) On balance, however, the patch made Tomcat slower at compiling and serving pages. At least, when I tested against the jsp-examples webapp (with index.jsp renamed back to index.html so it wasn't part of the test), time to compile and serve was about 2% slower. 3) I couldn't find any difference in serving compiled pages with the patch in place (I thought there might be a small improvement because the patch shrinks the .class files). Based on those numbers, I decided not to submit the patch as an option configurable separately from mappedfile, or as a non-configurable enhancement. But since the mappedfile documentation said it was intended for debugging, I thought the performance hit was acceptable. I didn't test your idea of a separate pass through the parsed nodes, but I did test code that, when about to create a new TemplateText node, checked to see if the previous node was also a TemplateText node, and if so, just appended its text to the previous node's (the ideas being that anything that conserved nodes might improve performance, and that I didn't like duplicating logic from another part of the Parser, either). But that was noticeably slower (I've forgotten the numbers entirely) than the patch I submitted. Anyway, I submitted the patch as an enhancement, so I can't complain if it gets implemented differently or not at all. The above is just to help folks make an informed decision. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
