hlship
commented
15 years ago I've checked this into a branch, but I'm not sure it will be worth the effort. Mostly what gets cached are text nodes, so the real savings will be the cost of escaping the HTML entities inside such text nodes ... and that can be accomplished in other ways as well and you still pay the cost of maintaining the view cache. Until I have a test bed with a realistic-ish application and the ability to reproduce performance results, it is (no longer) clear to me that the invariant optimizations will be worthwhile. Perhaps real applications with significant amounts of markup (to support a real L&F) will make optimization worthwhile ... but likely not, in a modern CSS-driven world.
The viewbulider (the center of the template, defview, etc. macros) should be able to do some static analysis of the views being constructed. Some portions of the generated code will be rendering invariant portions of the template: sections where everything is a fixed keyword or string with no calculation or external dependencies (such as symbols or function calls).
Using meta data we can tag the generated code to identify which forms are invariant, and which are truly dynamic. At an appropriate point, we can wrap the invariant parts in a global singleton, to render it once (on demand) and keep the rendered portion.
Should be tunable, since its probably more efficient to keep rendering small portions of markup than to introduce the overhead of managing an atom to cache the invariant result.