Apache Velocity performance pitfalls? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

W开发者_运维技巧e are using Apache Velocity for website templates and some of them are getting complex. Have you noticed any performance issues with certain Velocity features? And how did you get around them?

---

First of all use the latest velocity library(1.7 or 1.6.4). Version 1.5 contains some serious performance issues!

Also here is the list of parameters that you must tweak on production environment:

1. velocimacro.library.autoreload - should be set to false
2. file.resource.loader.cache - should be set to true
3. file.resource.loader.modificationCheckInterval - should be set to -1
4. parser.pool.size should be increased if default value is not big enough(default value is 20)

---

The most important feature people often overlook is resource loader caching (off by default) which boosts performance quite a bit (file.resource.loader.cache).

#parse directive also has noticeable performance impact, try to use it only to avoid code duplication, not to just split templates into logical parts.

If your templates becoming quite complex in terms of logic maybe it would be possible to shift that logic to a controller and provide a template with ready to render data structure.

I didn't notice any performance drops from Velocity, when I was testing Velocity speed before switching from JSP they were constantly 50% faster on any template I threw at them. Currently we generate sites with thousands of pages rendered from Velocity templates and it is lightning fast, very satisfied with performance.

---

We try to cache the byte[] in the ASTText node to avoid encoding the output text too much times.