velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Colson" <>
Subject RE: Velocity Performance Related Queries
Date Wed, 15 Sep 2004 16:43:53 GMT
Krishnan -

> Thanks for the suggestion. Changing the 
> modificationCheckInterval to -1 did 
> shave off a great 2000ms and now it takes around 1300 ms to 
> render a page. 
I'm guessing there was a typo there somewhere, right? Didn't you say before
that 1060ms was the avg? Or are there really some that were taking 3300ms? 

I'm wondering how much of the performance hit is due to velocity -- versus
the objects that are in the context.

I'm not a Velocity Internals expert, but a VelocityContext I think is super
lightweight (essentially a hashmap). Templates and Macros are cached, so
that doesn't seem a likely culprit.

Personally, I've often had objects (SlowUser) that are the real problems.
During rendering, I'll find that SlowFoo may have some lazy instantiation
aspect. One case I had was an object that performed an LDAP lookup each and
every time SlowUser.getUsername() was called. 

My first fix attempt was to modify SlowUser so that it cached the
username... but that still meant that this was still super slow, due to LDAP
lookups for each iteration:

#foreach ($user in $ListofSlowUsers)

Next optimization pass was to grab the username from a DB call, cache that,
and create a read-only hashMap FastUserMap -> copy the essential bits of
SlowUser into the map, and rendering was super fast. 

Summary -- usually the Velocity rendering IS super fast... it's the objects
in the context that are usually slow. But of course, your mileage may vary.


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

View raw message