(switching subject lines -- please use this one).
Nice email, Jason. Makes a lot of sense to me. For a long time Velocity
was much faster than JSP, actually. Probably not the case anymore, haven't
measured it recently. I haven't seen any data as to specifically how fast
Velocity is vs. JSP or other tools - Ahmed do you have benchmarks you might
share?
There's a type of compilation going on with Velocity, of course. Templates
are read in, converted to a parse tree, then cached.
On a related subject, here's been some excellent work on memory usage
improvements that is currently sitting (with discussion) at
https://issues.apache.org/jira/browse/VELOCITY-223. I'm looking forward to
seeing that work move into the code.
WILL
On 5/3/07, Jason Pettiss <[EMAIL PROTECTED]> wrote:
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]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
