On Wed, Aug 20, 2014 at 3:00 AM, Alvaro J. Genial <[email protected]> wrote:
> > > On Wednesday, August 6, 2014 7:51:09 PM UTC-4, Russell Keith-Magee wrote: >> >> Hi Alvaro, >> >> Firstly - congratulations - sounds like an interesting package. However, >> you may find that django-users is a better forum to announce something like >> that. Django-developers is the forum for discussing the development of >> Django itself, and while most of the people on this list also use django, >> django-users is a bigger audience. >> >> > Thank you--that's a good suggestion. I'll post an announcement there after > ironing out any remaining major issues. > > >> Secondly - the "would I use this" question... maybe. Faster templates are >> obviously a good thing; I'd be interested to see exactly how much faster >> (and how much faster compared to a "known fast" alternative template >> language like Jinja2). I'm especially interested to see how it's handled >> custom template tags, because that has always been the sticking point for >> faster *native* Django templates. >> >> > Makes sense. I have a simple benchmark script (synth/tests/timings.py) > that *roughly *suggests ~27x faster on Ubuntu, ~20x faster on OS X and > ~11x faster on Windows, given a somewhat esoteric set of machines, > templates and data. (The details are at the end of this message, and all > the standard benchmark caveats apply.) If there's an official benchmark > suite I can run it as well and post the timings. At the moment, overall, > the difference seems to range from 10x to 30x. (Python2 vs. Python3 doesn't > appear to affect the outcome much, nor does 32-bit vs 64-bit.) > Is that comparison against Django templates on CPython? What about comparisons with PyPy? Or with the equivalent templates in Jinja2? I'd also be interested to see your results against the speed.python.org Django benchmark (which is mostly template driven) > Anyway, with the bulk of the functionality completed, I can now focus on > performance, so I expect those figures to go up, as there's a lot > of low-hanging fruit. > > Separately, I've been studying the differences between Django's template > language and Jinja2 and I'm considering implementing the latter natively as > well, especially because: there'd be a lot of shared code; the Django > integration glue is already there; and it seems to allow even more > opportunities for speed gains. Any thoughts? > If you've got the time and inclination to implement it, then I'm sure nobody would object - especially if you get an improvement in performance :-) > Lastly - you've implemented a binding layer to a new template language. Is >> there anything in Django's core that you would like to see modified that >> would make your life easier? Using a custom template language is an area >> where many people claim it's impossible to do (despite evidence to the >> contrary), so we'd like to make it as easy as possible to do. Any >> suggestions/requests? >> >> > Thanks for the offer! Currently, the best thing I can think of is to > actually try it on real projects and report significant issues and > differences in output. > > One relatively small improvement I just thought of is to allow > template loaders to parse top-level templates from a file path rather than > accepting the source as a string. (Perhaps this is possible already?) > It's not possible in the loaders that Django ships, but you can write your own loader (and it's a pretty simple piece of code, too); see django.templates.loaders.filesystem for the current filesystem loader. The only caveat - and I'm not sure how you plan to reconcile this - is that templates are "named" in code - so, you say "render(request, "my template.html", mycontext)". That means that the public API to template is string based; no scope where the end user is passing around file pointers. 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/CAJxq849BMf%2BHsqdDiz9bs%3DukmZ4vg7HX-8VbePVfHxkSbEOSdQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
