I've made some benchmarks. The results are:
jinja2 empty for 0.028 s
jinja2 include 1.094 s
django empty for 0.435 s
django include 2.134 s
Where "empty for" is an empty loop repeated 50 times:
{% for i in range_ %} {% endfor %}
And include is a similar template where the loop body includes another
template
(which is empty) inside for loop:
{% for i in range_ %}{% include "i" %}{% endfor %}
The full code is available here: http://pastebin.com/DWjE1axV
Note that including is only 1.5x faster in Jinja2 compared to Django.
Surprisingly, the main speedup is in executing for loop (19x), not it's
body.
On Friday, February 21, 2014 11:07:30 PM UTC+1, Kevin Christopher Henry
wrote:
>
> Hi Christopher,
>
>
>> ... checks the template extension and dispatch to
>> corresponding function from `django.dtl` or `jinja2`.
>>
>
> The mechanism for distinguishing the two kinds of template needs to be
> more flexible. For example, let's say I want to override a third-party
> template with my own Jinja template. In that case I need to use the same
> name (.html and all), but I want it to be processed by Jinja. The way
> django-jinja solves this is with a setting that provides a regular
> expression to determine which template names get processed by Jinja. That
> may not be the best way (I can imagine that regular expression getting
> hairy with a lot of "or" clauses), but just looking at file extensions
> isn't enough.
>
Unfortunately, you're right. So I will follow Aymeric Augustin's idea: at
the
beginning of every template there will be "{# syntax: django #}" or "{#
syntax:
jinja2 #}". If the template lacks such declaration, django template is
assumed.
I don't have a comment on the merits of your approach to inheriting from
> DTL templates, but personally this is not something I've ever needed to do.
> I'm sure there are use cases for this, that's just my experience.
>
> By contrast, something that I very often want to do is use third-party
> Django template tags in my Jinja2 templates. Right now there's just no way
> to do that (that I know of). So, if you're taking requests, please solve
> that problem. :-) And if you're forced to prioritize, I think that would be
> more useful than being able to inherit from DTL templates.
>
What kind of support do you except for third-party template tags? Suppose,
that
`cycle` tag is not builtin. Would it be acceptable to write sth like that:
dtl cycle '1' '2' as rows
It could be quite easily implemented as a Jinja2 extensions. Of course, I
guess
that you'd prefer this style:
cycle '1' '2' as rows
Unfortunately, it cannot be done easily. Each of template tags should map
to a
new Jinja2 extension. But the list of extensions must be given to
`Environment`
constructor and cannot be changed (at least this is what documentation
says).
What can we do?
1) We can tamper with Jinja2. Maybe it is possible to change list of
extensions
after environment creation? I will investigate it.
2) We need to know all template tags before rendering first template. All
tags
will be available in all templates. The drawback is that you have no
modules
that you can `load` when desired.
BTW, what about built-in template tags? Are there any issues?
>
--
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/ecf638ce-5811-4234-bd40-964178763090%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
