On 5/3/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
(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.
me too. what are we waiting on there? confirmation of the improved
performance? a patch that incorporates the latest of the discussion?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
