You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Twan Kogels <tw...@twansoft.com> on 2004/06/16 13:30:42 UTC
A more efficient velocity template?
Hello people,
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:
-------------------------
62.38% - 854 ms -
org.apache.velocity.servlet.VelocityServlet.mergeTemplate()
35.35% - 484 ms - kaart.KaartController.handleRequest()
-------------------------
The "handleRequest()" (second line) is my custom code making queries and
doing logic. The "mergeTemplate()" seems to be velocity parsing and filling
the template.
The template is a complex one with a lot of custom macro's and if and else
statements.
I'm currently using velocity 1.3.1.
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?
Thanks!
twan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: A more efficient velocity template?
Posted by Nathan Bubna <na...@esha.com>.
Twan Kogels said:
> Hello Nathan,
...
> > > 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)?
i would say no. i doubt it would help speed things up much, if at all, and it
would be a major design faux pas. :) keep the view/UI logic in the template.
...
> > > 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 :-))
...
wow. that's cool!
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: A more efficient velocity template?
Posted by Twan Kogels <tw...@twansoft.com>.
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 velocity.properties 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...
>http://jakarta.apache.org/velocity/developer-guide.html#Configuring%20Resource%20Loaders
>
>http://jakarta.apache.org/velocity/developer-guide.html#Velocity%20Configuration%20Keys%20and%20Values
Thanks for the helpfull pointers and tips!
Twan
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: A more efficient velocity template?
Posted by Nathan Bubna <na...@esha.com>.
Twan Kogels said:
> 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.
> 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.
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' )
- 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...
> 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...
http://jakarta.apache.org/velocity/developer-guide.html#Configuring%20Resource%20Loaders
http://jakarta.apache.org/velocity/developer-guide.html#Velocity%20Configuration%20Keys%20and%20Values
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org