views:

33

answers:

1

Working on a legacy project that includes a fair amount of velocity. Not sure on what I can safely post on her (copyrights and all) but I'll try to be an clear and concise as I can.

We have several templateX.vm files. They're not large, only about 200 lines or so long. They do not rely on outside resources. They do not use any macros. I have narrowed the long rendering times I am experiencing to 3 files, each about 300 lines long (each of them make one #parse call to the same "common.vm" file, which about about another 100 lines long. It's just some javascript).

Each of these 3 files, when left in and not commented out, cause the rendering times to become horrendous. A entire minute or two each time one of them is left in.

Some needed details. Due to business/project requirements, each file is rendered at least twice. (One render is hidden and swapped in when needed).

I am not sure where to begin to figuring out how to optimize this or at least figure out where all the slowdown is occurring. What I can tell you using the profiler VisualVM is that when ONE call to a problem file, there are 3.3 million calls to Parser.look(). This makes me want to think it's parsing the file too many times. I am only seeing 6 or calls to a merge().

Thanks for any assistance or brainstorming of ideas. This has long been a bottle neck of the system and it would be great to make any improvements. What are some common mistakes people make when using velocity?

A: 

It sounds like you have some very large or infinite loop that involves VTL evaluation (#parse, #evaluate, $render tool use or something that like that)

Nathan Bubna
Seems like our calls to #parse are very costly. I have file.resource.loader.cache set to true. Is there any more settings I can tweek?
bobber205
make sure resource.loader=file, to ensure caching is on.look in your logs for exceptions.try answering the loop/recursion question.#parse is only expensive if the template being parsed is expensive
Nathan Bubna