Hi Curtis, If true, this would certainly be a reasonable improvement.
However, I'm not sure it would be a great GSoC project. This would have to be posed as a "optimise the template language" project, which is problematic when we don't know for certain ahead of time where the problems lie. We're not likely to accept a 12 week fishing expedition, because there's a possibility that the student will run out of things to fix after 2 weeks. The only way that this would be an acceptable GSoC project would be to present a pre-analysis that demonstrated that there was 12 weeks worth of things than needed to be optimised. However, my experience with optimisations of this sort has been that *finding* the problem is usually 90% of the work. Once you know *what* is slow, cleaning up a code path or caching a slow lookup is comparatively easy. However, if someone wants to look for sources of optimisation outside of GSoC, I'd encourage them to do so. Yours, Russ Magee %-) On Sun, Feb 9, 2014 at 8:56 AM, Curtis Maloney <[email protected]>wrote: > Can I suggest a 3) to this? > > After getting involved with the internals of the template engine recently, > I came to the suspicion that a lot of the speed issues come from highly > defensive coding. > > Now, this is generally to be expected when safety is more important than > speed, but I am moderately firm of the opinion that some careful analysis > of the template code could help reveal places where the same guard [such as > mark_safe, force_text, etc] is being applied repeatedly but could be > avoided. > > So my (3) to this is to analyse the template code paths sufficiently to be > able to identify places where these guards can be omitted safely. > > -- > Curtis > > > > On 9 February 2014 11:11, Russell Keith-Magee <[email protected]>wrote: > >> >> On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela < >> [email protected]> wrote: >> >>> Hello! GSoC 2014 is coming and I'm thinking about issue to work on. >>> >>> The template system is one of the components that are of special >>> interest to me. >>> One of the major issues is that rendering templates is slow. The problem >>> could >>> be solved by compiling template to Python bytecode, but it seems to be >>> really >>> hard to achieve, given that there was an unsuccessful attempt. >>> >> >> This should set off a red flag for you. The GSoC project to byte code >> compile Django's templates was implemented by Armin, the same person who >> wrote Jinja2 - and yet the project didn't fully succeed. It's worth >> investigating *why* this idea failed, because it flags one of the reasons >> why "just adopt Jinja2" may not be a viable options. >> >> >>> Why not switching to Jinja2? I thought that somebody else proposed this >>> idea >>> but I couldn't find any discussion; so, please, point me to the >>> discussion if >>> the idea was discussed, otherwise let's discuss it! >>> >> >> It's been proposed in jest, and it's been accepted in jest as well :-) >> However, I don't think there's been a serious proposal to this effect. >> >> >>> The pros are obvious: 1) fast templates, 2) less code to maintain, 3) >>> lot's of >>> companies use Jinja2 (because of slowness of default template system) and >>> builtin support for Jinja2 would be beneficial for them (thing about >>> integrating Jinja2 with settings like TEMPLATE_DEBUG). >>> >>> Now the cons. First of all, one of the design decision is that Django >>> has no >>> dependencies. We can overwhelm it by "static linking" -- I mean copying >>> Jinja2 >>> code into Django. At the first glance, it may look like a horrible idea, >>> but >>> think about it in a different way. If we don't switch to Jinja2, we have >>> to >>> maintain entire template system and fix every bug as well as implement >>> new >>> features. If we switch, Jinja2 developers can do this job for us. We >>> only need >>> to forward tickets to Jinja2 developers and update the static linkage. >>> >> >> We're unlikely to vendor a copy of Jinja2. If we went down this road, >> we'd be much more likely to look at using dependencies defined in setup.py. >> >> >>> The second big problem is that switching is a big change and backward >>> compatibility matters. We will need to support both the deprecated Django >>> template system and the new one. However, it doesn't mean double work -- >>> we >>> don't need to implement new features for the deprecated system, only bug >>> fixes >>> will be required. Also note, that a lot of companies uses Jinja2 and >>> switching >>> from third-package Jinja2 to Jinja2-builtin-Django isn't an enormous >>> change at >>> all. >>> >> >> Untrue. It *can* be a *very* big change. One of the biggest problems is >> backwards compatibility for custom template tags. There are a lot of these >> out there in the wild, and the way Django defines custom template tags is >> one of the major reasons that a bytecode approach to Django templates is >> difficult. >> >> >>> I'd like to hear your opinion. Feel free to comment! >>> >> >> Personally, I'm -0 on this proposal as described. >> >> Although Jinja2 and Django template share a common base syntax, Jinja2 >> includes a bunch of features that I'm not wild about. Django's templates >> are *deliberately* hobbled to prevent the injection of business logic into >> templates. Jinja2 template allow for function calls, array subscripting, >> and all sorts of other programming language structures. I'm not saying >> these things are inherently bad; I'm saying there's a reason why Django >> hasn't included them, and I'm not wild about the idea of switching to a >> default template language that allows them. >> >> I'd be a more supportive of two different spins on this project idea: >> >> 1) Try to pick up where the 2012 GSoC project left off, and continue the >> work to byte code compile Django's templates. However, this project is >> unlikely to get off the ground without a concrete proposal to get around >> the problems encountered the first time around. >> >> 2) Work on the internals of Django to decouple the template engine, so >> that (a), Django's template language is a standalone in the same way that >> Jinja2 is, and/or (b) there's a clean interface so that it's possible to >> define a clean Jinja2 module that you can drop into your Django stack. >> >> A good solution for (2) would set the groundwork for a *long term* >> transition to Jinja2 templates, but would also allow long term backwards >> compatibility, as the Django template language could be maintained long >> term, even if it is dropped as an officially supported option by Django >> itself. >> >> BTW, I'd like to have an internship in the late summer. It's impossible to >>> work at GSoC and have an internship at the same time, but I really want >>> to do >>> both, so I need to start GSoC as early as possible, at 21 April or even >>> earlier. Is it possible? >>> >> >> It depends on exactly how long the overlapping period is. If it's a >> matter of a week or two, and we have a good proposal from a student, I >> suspect we'd be happy to internally shift the dates for the GSoC by a >> fortnight to accommodate them. In the past, we've accommodated students who >> have a 2 week exam period in the middle of the GSoC; I don't see why we >> wouldn't extend the same courtesy to an overlap at the end of the GSoC. >> However, the longer the overlap, the less likely we are to be accommodating. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAJxq8489OcnOg_KE6PsAghqF6smSY8hRW3gKsmoGT%2Bec1kBMiw%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAG_XiSAXUZDMJ04k88nh%2BZW9J2khCGrpQTe9WiK5U_%3Df4Ad%2Bhw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq849b-n3sh5Rm%3DBeuCyD85rNzRnGvgCSun1YBu0iVcwQKqw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
