On 1/18/07, Tom Schneider <[EMAIL PROTECTED]> wrote:
One of the possibilities I was discussing with Phil yesterday was to implement freemarker caching on the WW side of things--just like we do with OGNL. In WW if we're not in devMode, then I think its safe to say that we can read the template once and never reread it. This would eliminate the need to move the ftl files out of the jars and also eliminate the penalty of not having an ftl files in your own custom theme. This could (should) also be moved in struts2 as well. That way, in non-devMode we would get the best performance we can, out -of-the-box. (It certainly would have saved me a lot of effort--that was where all of our performance woos came from) Tom
I'd like to pick in on this one :-) Basically, there are two sides: we have the 'internal' Freemarker rendering for UI components, and we have the Freemarker result, which both share the same caching/template loading/.. . Now, as Tom said, the defaults are not so good (for the internal UI rendering). Not only does Freemarker have a default delay of just 5 seconds, but it also doesn't use its strong reference cache. [2] We can choose to split up the configuration for internal (UI components) and external (results) rendering, where we have a infinite caching for the internal use, and freemarker.properties - adaptable settings for external use, with better default settings when not in development mode. In my opinion, users should not have to worry about the internal rendering when just using the framework, unless they set devMode on (in which case constant reloading is allowed, and even required), so we should set the default settings accordingly. Thoughts ? Phil [1] https://issues.apache.org/struts/browse/WW-1654 [2] http://fmpp.sourceforge.net/freemarker/pgui_config_templateloading.html
Ted Husted wrote: >> Even though this is for WW, almost all of it is applicable to Struts 2. > > This is a key phrase. There are a lot of very successful WW > deployments out there, with the same performance levels. > > We really need to setup our own benchmarks, so that we can run them > with the templates deployed. I'd love to do this myself, but I'm > totally time-deprived right now. > >> Eventually we'll move this to S2 and update it, but so few people are >> using Struts 2 right now, I think this is adequate. > > That's going to change quite quickly. Even though we're still in beta, > people are already posting jobs for S2. Even though the benchmarks > might not tell the whole story, narrowing the cycles would make it > easier for more people to adopt S2 (And hopefully some of those will > lend us a hand. Even with the merge, we still don't have more active > committers than we had a year ago.) > > -Ted. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- iDTV System Engineer "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." - John F. Woods --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
