On 2/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > > Heh, if freemarker can parse Velocity templates, then maybe. Like I > > said, I've got thousands of temlates (not to mention users) that would > > need converting... > > Actually, we've got an automatic conversion tool that works fairly well, > reads in VTL and spits out FTL. A real miracle. The modern equivalent of > turning water into wine.
Heh, if VTL to FTL transformation is water to wine, then perhaps XML transformation is parting the Red Sea? What templating feature is curing leprocy or blindness? I have to argue that that would be mathematical functions that support decimal calculations. Now if only you had a conversion tool that would change how my users had been trained. That'll take some real divine power. > > Yes, it is a fair point as to whether the serializable API would be > > faster, but I would hope so. Given the number of pages, I have to > > turn off memory caching, so every page requires parsing. > > What you need, I think, is the MRU cache. Yeah, gonna throw that in and run some performance tests. Fortunately the cache strategy is very easy to swap out... I only wish the parser pool management was as easy to swap out... > > My benchmarks calculated 37ms/MB to read a file (just read into a > > string), 754ms/MB to compile (create a Template object), and 31ms/MB > > to merge it with a simple context. Obviously if I can eat into that > > 700+ms/MB rate by serializing the ASTNodes or something else, then > > that'd be great. > > Maybe the question is how much of the overhead in parsing VTL is in the > lexical scanning. From what you're saying it seems that not much of it > is in actually physically reading the file. Offhand (I could be wrong) > it seems the gain you'd get from a binary storage format is that, > instead of scanning ahead for #foreach and all the other tokens they are > stored as a single byte, say. Ergo, my idea of serialization. :) > But probably the solution you'll implement will be some kind of MRU > cache. Or you can just buy a lot more RAM, I guess. :-) Yeah, unfortunately more RAM will only get me through this year. With our growth projections, I'll need to solve this in the fall. -- 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]
