Hmm. It's doesn't seem quite that straightforward to me. Caching isn't always a parse-all-up-front situation, there are modification check intervals, and most of all, there are things that can heavily use evaluate(...) (RenderTool, #evaluate, etc) instead of getTemplate(...).
This is something i put in the "if it's not broken, don't fix it" category. If you know that you don't need a parser pool, then by all means, set it to 1. That's why it is configurable. But i would worry about changing that on people without some real numbers and case studies. Until then, no one has complained about the extra parsers kicking around to my knowledge. On Sun, Nov 23, 2008 at 1:33 PM, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > That's interesting-- hadn't thought that through. I'm sure only a few > people run without template caching. > > WILL > > > --- > Forio Business Simulations > > Will Glass-Husain > [EMAIL PROTECTED] > www.forio.com > > > On Sun, Nov 23, 2008 at 12:41 PM, Byron Foster <[EMAIL PROTECTED]> wrote: > >> I'm curios about a section in the docs here: >> >> >> http://velocity.apache.org/engine/releases/velocity-1.5/developer-guide.html >> >> Under the section "Parser Configuration" >> >> Unless I'm missing something I think it's a little misleading to discuss >> performance and the parser.pool.size configuration. It contains a reference >> to being Slashdotted and how the parser pool is relevant, but when Velocity >> is used in this way templates should be cached, and the parser pool should >> not play a role. In fact, I'm not even sure if it would be a big deal if >> the parser pool was always set to 1! >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
