On Thu, Mar 4, 2010 at 7:29 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > Django Template Compilation > ===========================
First up, this looks like a solid proposal Alex. Anything that speeds up template generation is good, and if your indicative stats turn out to be representative of real-world performance, it would be a major gain for Django. I have a couple of quick concerns that pop out. In all likelihood, they aren't actually problems, just areas that require clarification in your proposal. > Templates will be compiled by turning each template into a series of > functions, > one per block (note that the base template from which other templates extend > is > a single function, not one per block). ... > After an intermediate representation is created a compiler is invoked which > translates the IR into Python code. This handles the details of Django > template > scoping, spilling variables in the event of conflicts, and calling template > tag > functions. You don't ever say this explicitly, but I presume that the plan is to do this as an in-memory construction -- that is, the intermediate representation is handled in-memory, not as a python file on disk. You're proposing to writing a (2 pass?) compiler, not a code generator, right? > To provide an optimal solution we must know which variables a given template > tag needs, and which variables it can mutate. This can be accomplished by > attaching a new class attribute to ``Nodes`` and passing only those values to > the class, (instead of the full context dictionary). Subsequently, we would > only need to mirror a few given values into the locals, and since these are > known names, we avoid degrading the local lookups into dictionaries. Old-style > ``Nodes`` will continue to work, but in a less efficient manner. The term "less efficient" needs clarification here -- less efficient than a compiled node that has been specifically optimized for compilation, or less efficient than existing template rendering? It's completely understandable if a node doesn't render as fast as it's optimized and compiled counterparts, but I would consider it a failure if a compiled template resulted in a slowdown when compared to existing non-compiled rendering speed. > Alternate ideas > --------------- > > James Bennett has suggested making template compilation something that is > opt-in by use of a custom template loader. The major advantage of this > approach > is that we can require all ``Nodes`` to specify the names they use, and thus > not have to deal with mirroring the locals back and forth, which drastically > reduces the possibility of performance regressions. I am in favor of going > with this proposal as it gives us a clear transition between the current > implementation and the future (see next section). I concur. The template system is a criticial part of enough Django stacks that I'd like to see this as an explicit opt-in feature. > Long Term > --------- > > In the short term almost all template tags will be old-style (consider the > number of tags using the "as X" idiom to modify the context). However, a long > term goal should be to move to exclusively compiled template tags. This has > several benefits: > > * Fewer codepaths to maintain > * No chance for differing semantics (this follows from the first) > * More consistant performance. > > One of the critical goals of this project will therefore be to develop the API > for template tags in a manner where old-style tags can easily migrate to the > new form. I'd like to see a little more elaboration here - exactly what do you mean by an "API for template tags"? Do you have any initial thoughts on what this would constitute this API? What sort of problems need to be addressed or solved? Does this have any crossover with the eternal pony to "make template tags easier to write?" > Goals > ~~~~~ > > As with any good project we need some criteria by which to measure success: > > * Successfully compile complete (real world) templates. > * Speed up templates. For reference purposes, Jinja2 is about 10-20x faster > than Django templates. My goal is to come within a factor of 2-3 of this. > * Complete backwards compatibility. > * Develop a complete porting guide for old-style template tags to minimize > any > pain in the transition. Looks like an interesting proposal, and certainly one with aims that make it attractive for Django's core (assuming you can deliver on the performance gains you suggest are possible). Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
