velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Twan Kogels <>
Subject Re: A more efficient velocity template?
Date Thu, 17 Jun 2004 08:19:32 GMT
Hello Nathan,

> > I'm currently in the process of making a webapplication a bit faster. I use
> > a profiler to look at my code and see where possible bottlenecks are.
> >
> > I found out that velocity is parsing a template relative slow:
>parsing or merging/rendering?  in other words, do you have template caching
>turned on?  i'm guessing you probably already know this, but it's worth saying
>if only for the archives...  if you don't have to pay for the initial parsing
>of templates (especially complex ones) every time, then that should help a
>lot.   also, if you do have caching on and you are using a resource loader
>that supports the modificationCheckInterval property, you might consider
>raising the interval.

Yes, i've used the default and turned .cache on. I also 
increased modificationCheckInterval to 20 seconds.

> > The template is a complex one with a lot of custom macro's and if and else
> > statements.
>sounds like part of your problem's right there. :)  as Peter said, moving
>business logic to java can help.  java is faster than VTL.

But my macro's don't define business logic, they are mainly used to "print" 
common interface components like a menu or a button "ok" "cancel" combo. I 
also have a macro which prints a fieldname + fieldvalue combo. This combo 
is called about 40 times in one template. Is it wise to move this macro to 
java code (tool) and call it like: $fieldtool.print($name $value)?

>also, there are little things that can be done:
>- define your macros globally so they are parsed on velocity startup.
>- use single quotes (') for strings in VTL that don't need parsing.  e.g.
>    $tool.getFoo('bar')  or #set( $title = 'Best App Ever' )

That's a handy tip, i see the template uses many " where ' could be used. 
I'll do some replacements here.

>- remember that macro arguments are passed by name and re-render each time
>they are used within the macro.  so if you have a macro like:
>     #macro( list $bullet $items )
>     #foreach( $item in $items )
>     $bullet - $item
>     #end
>     #end
>then don't do things like:
>     ##NOTE: we assume here that getBullet() is costly
>     ## and always returns the same value when given the same arg
>     #list( $tool.getBullet('bar') $tool.getList() )
>because that will result in $tool.getBullet() being recalled for every item in
>the list.  instead, do this:
>     #set( $b = $tool.getBullet('bar') )
>     #list( $b $tool.getList() )
>and getBullet() will only be called the one time.
> > I'm currently using velocity 1.3.1.
>from what Peter says, Velocity 1.4 sounds faster.  i know it does have
>introspection improvements, so i'm not surprised.   also, i believe Java 1.4
>has big improvements in reflection performance over previous versions.  since
>Velocity uses a lot of reflection...

I installed velocity 1.4 and after a bit of struggle with a nullpointer 
exception it worked. I don't know what you guys did but the speed increase 
is enormous:

67.55% - 329 ms - kaart.KaartController.handleRequest()
22.17% - 108 ms - org.apache.velocity.servlet.VelocityServlet.mergeTemplate()

(the old situation as a reference)
62.38% - 854 ms -org.apache.velocity.servlet.VelocityServlet.mergeTemplate()
35.35% - 484 ms - kaart.KaartController.handleRequest()

And i only replace 1.3 with 1.4 :-))

> > Are there a documents/urls/tips available which discuss or give tips
> > regarding on how to construct efficient templates or make velocity a bit
> > faster?
>again, for the record...

Thanks for the helpfull pointers and tips!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message