The performance page suggests hand building XSPs:
Consider turning your XSPs into Generators by hand and call them
directly. Of course you don't need to do this for all pages, but
it's recommended to it for those which are heavy loaded.
You can try it this way:
Cocoon will compile your XSP's into Java classes (see
tomcat/work/..../org/apache/cocoon/www/my_xsp.class). After that,
add the generated Generator to the Sitemap:
<map:generator type="myXSP" src="org.apache.cocoon.www.my_xsp"/>
And use it:
<map:generate type="myXSP"/>
Is the xsp dependency checking so expensive that this
it worth the maintenance cost is incurs?
I'm not aware of anyone having benchmarked it. My gut feeling is that I could shave some unnecessary objects and less than optimal code off the auto-generated version by either starting from scratch or working with the generated java and hacking away. How much that would get is anyone's bet. When I was developing for a high traffic site I felt better creating the Generator myself, but since when working on lower-traffic code I've been happy with XSP.
Is there more
going on that just stat()ing the xsp file and the logicsheet
it references?
You'd have to confirm this independently, but I think it's doing a delayed refresh check on getLastModified() of the file and its dependencies. Shouldn't be too bad.
Is there a build-time option to precompile XSPs without doing it by hand?
Yes I think but you'll need to dig it out yourself.
Hope that helps,
Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
