Actually the translation to Java you find in JSP was a lazy way out of
needing to write an expression interpreter (pre-dot-com era I don't
think anyone was really banking on JSP). But it turns out tight binding
is annoying most of the time. In the past few years you've seen JSP
trying to look more modern, with more and more use of EL / taglibs, tag
files, and with JSP 2+ you can even just ${varHere}. So what you see is
JSP gets slower and slower, while compilation provides less and less
value. Meanwhile more dynamic template languages flourish, because
they're much faster for development, and just about as fast at runtime.
Without tight binding, I don't think you'd see a performance gain from
velocity2Java. Reflection performed by a "compiled servlet" is the same
cost as reflection performed by the (compiled) velocity engine.
Old-skool JSP is fast because it avoids reflection entirely (or really,
has no ability to do so).
Besides the fact that compiled JSPs are horribly bloated (I frequently
see 800k+ when tag libs and tag files and implicit expression language
is in use), and variously inefficient depending on your translation
engine, I really hate that all the schmoo -- all the content -- usually
ends up as static String constants cluttering up the constant pool...
this renders that pool inefficient for internalization of IDs and
generally slows everything /else/ down. Velocity does not do this--
once you run it the first time, it is very predictable in time and space.
I think Velocity's main bottleneck is the uberspector. But working on a
velocity2Java would be MUCH more fun than trying to optimize Java
reflection. :-)
--jason
Ahmed Mohombe wrote:
Rather than sniping, how about some concrete ideas for what you'd
like to
see next? Or better yet, since you are hanging out in the developer
list,
some test cases or patches?
I have a few ideas, but I don't know how to implement them :). The
"obvious" need
of something does not imply the ability to implement it :).
E.g. one that might help improve the performance of Velocity would be
a "velocity2Java" compiler, something that could be run like the JSP
compiler. AFAIK the big part of performance gain
of JSP in the last few years come exactly from this corner.
It would be a fantastic gain if for a first version the compiler:
- would work only off-line, so not at runtime like the JSP one, so
only "pre-compile".
- would be able to convert only part a of the templates (e.g. those
pretty static and with big contexts), so not 100% coverage.
At least these "generated" Java files would be than easier to profile
than the Velocity engine + templates.
Well, just an idea, but I really don't know if it's feasible for
Velocity.
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
