I have convinced my self [with absolutely no hard evidence, just familiarity with the code] that the template engine is overly cautious when it comes to ensuring values are strings and are escaped properly.
After a while I believe layers and layers of caution have accrued, and nobody is sure any more where these have overlapped excessively. I believe a motivated person could create a call graph and find at least some cases where some of these cases could be removed to the benefit of rendering performance. My prior experience with the template engine has convinced me there is little benefit to optimising the _parsing_ of templates, as anyone concerned about template parsing speeds should generally be using the caching template loader. [Yes, I realise there are other cases, but I don't believe there is a lot left to optimise in the parsing -- happy to be proven wrong] -- Curtis On 12 March 2015 at 15:31, Preston Timmons <prestontimm...@gmail.com> wrote: > Hi Oleksii, > > I found that cProfile isn't that helpful when rendering templates. There > are a lot > of function calls and the output is too verbose to really reveal where > Django > spends it's time. > > Also, keep in mind that rendering is only one step of the template cycle, > and > usually only a small part of it. There are these steps to consider: > > * Template loading > * Lexing, parsing and compiling > * Rendering > > Here are some recent benchmarks I've done on the template engine: > > https://groups.google.com/d/msg/django-developers/VFBLAoPSplI/pPzOYm3PUVQJ > > From what I can tell, if we compare Django templates to Jinja2, which are > considered quite fast, the biggest visible difference doesn't come because > Jinja2 has a faster parser or renderer. It's because it maintains an > internal > cache. Jinja2 only recompiles templates when it has to. > > Depending how things go with ticket #15053, internal caching might become > part of Django, though. If that's so, your proposal will need to hone in > on > identifying other specific areas you think performance can be improved. > > The Django parser and lexer are parts that could be completely rewritten, > for example, while easily maintaining backward compatibility. Changing the > rendering layer is much more difficult because multiple 3rd-party libraries > depend on the Node class. > > If you're serious about working on this, I suggest digging into the > benchmarks, > identifying an area that can be improved, and providing a proposal for how > you think it can be made faster. > > Good luck. > > Preston > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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/c16befb5-c12d-43cc-84a2-6931c245b8a5%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c16befb5-c12d-43cc-84a2-6931c245b8a5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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_XiSDwGquyEUsQ7s%3DUB1SuLje91Fwsh4pfanv77QxAj0U-3A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
