On Wed, 16 May 2001, Jon Stevens wrote:
> Costin,
>
> Once again, you impress me with your inability to understand a word of what
> I'm talking about. So, let me close this discussion with this:
No problem, I'm not that good at explaining either.
> If the speed of generating a .java file (or directly to a .class file) from
> JSP ends up taking more resources (ie: memory) and more time after the
> conversion to using XSLT as the transformation step, I will forward your
> comments above to you again and tell you "I told you so." I welcome the same
> response from you.
And I tried to explain: the xslt transformation is not significant
compared with the javac compilation ( it may add 5-10% extra ), and may
end up saving the javac in some cases - which would be a significant speed
improvement.
And I also tried to explain: JSP doens't take more resources, a particular
implementation ( generator ) may take more resources. The current
java-only generator will still be available, there are many ways to
compile the JSP page - and xslt has some benefits you can't get otherwise.
> As for your comments about Cocoon2, well, if you actually look at it, it is
> dog slow and *extremely* resource intensive. The only reason why there is
> *any* performance out of it is because there is a shit load of caching and
> compiled XSLT that goes on. This is something that I fear the development of
> JSP pages will not be able to take advantage of in the same way and as a
> result, development performance will suffer compared with what it is at
> today.
Caching is good and will be done anyway ( at least for runtime
). Generating code is supposed to be resource intensive if you expect
reasonable runtime performance - and I haven't heared too many people
complaining Resin is too slow.
> I find it funny that I seem to be the only one who cares about this issue.
>
> :-)
Yes, I find it funny too.
Costin
