Serge Knystautas wrote:
I'm working on a CMS that uses velocity template extensively (many
thousands of templates), and we're trying to figure out how to avoid
reparsing these templates over and over.
Have you actually determined that this is a bottleneck in your application?
First idea... does anyone have experience creating alternate resource
cache implementations? I've looked at the basic cache impl that's
available, and it seems like I could very easily swap it with an LRU
Map to avoid sucking up a lot of memory... we have perhaps hundreds or
maybe thousands of templates and couldn't keep them all cached in
memory. That could help reduce reparsing on the most heavily used
templates.
Well, you could look at FreeMarker. :-) I think we have a pretty good
MRU template caching implementation. I don't know too much about it, it
was written by Attila Szegedi, not me. It's probably pretty good. Attila
is a pretty thorough guy. This stuff is quite well tested. It's been
part of our stable release for several years.
Really though, something like caching the parsed templates (i.e., the
AST nodes) to disk
Well, you're talking about storing the AST in some format on disk, but
there is already a way of storing a VTL AST on disk and that is the way
it is stored already, as a .vtl file. I mean, it is not obvious to me
offhand why re-instantiating the AST from the disk in your scenario is
going to be that much more efficient than just reparsing the template
from its canonical VTL format.
I mean, at the end of the day, you're just reading the template (in some
format) off the disk again. Okay, you could have a binary format for
storage that is a bit more efficient than the VTL text format, but how
much difference would it make?
In terms of overall Velocity development, how much value added could
their be?
or somehow using bytecode generation or something
to avoid reparsing my templates every time and make this much more
memory friendly... if anyone has any experience or ideas with this,
I'd greatly appreciate it.
It's not likely that something like this would produce much value-added
to hardly any users. I'm only speculating but it seems unlikely that
whoever is involved in Velocity development would want to invest much
effort in this. After all, there are glaring problems in Velocity, like
whitespace handling, lame macro system, deficient error reporting, that
have not been adequately addressed in years. Surely they'd want to
address some of these things first.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
