Hi,
I've run this benchmark (https://github.com/prestontimmons/templatebench)
on my laptop and received following results – http://pastebin.com/kkyTcfi7.
>From what I see, internal caching mainly solves a problem with parsing.
However, rendering is still an issue, so I tried to figure out wh
Even with the cached template loader? Before realising it was unnecessary
one of the first things I did was hack something together that took the
nodelist from the include and stuck it straight into the for loop's
nodelist at compile time and it didn't make much difference.
Sam
On Fri, 13 Mar 201
2015-03-13 12:21 GMT+01:00 Sam Cooke :
> The test template we were using to test the performance was a simple:
> {% for item in item_list %}{% include "item.html" %}{% endfor %}
>
Bad luck -- including a template in a loop is one of the known pathological
performance cases of the DTL :-(
--
Aym
Preston - I'll send the template to you directly, I'm not sure how useful
it will be so I don't want to spend time checking if it's fine for public
consumption unnecessarily.
The test template we were using to test the performance was a simple:
{% for item in item_list %}{% include "item.html" %}
>
> I've done a couple of days of investigation into template performance
> recently trying to speed up our site and my main takeaway was that there
> was no silver bullet - no particular node taking up all of the time. I was
> mostly trying to optimise a particularly complicated template we re
I've done a couple of days of investigation into template performance
recently trying to speed up our site and my main takeaway was that there
was no silver bullet - no particular node taking up all of the time. I was
mostly trying to optimise a particularly complicated template we render a
lot in
>
> After a while I believe layers and layers of caution have accrued, and
> nobody is sure any more where these have overlapped excessively.
>
Do you have examples of which layers these are?
Escaping seems to happen in Variable, VariableNode, FilterExpression, and
render_value_in_context. I d
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 m
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
On Wednesday 11 March 2015 23:40:39 Oleksii Oleksenko wrote:
>- Profiling
> - run profiler (cProfile?) on all of these tests. As I see, basic
> algorithm (pseudo code) will look like this:
>
> for context, template in zip(contexts, templates):
> t = Template(template)
> c =
Also, I would like to know, if I understand this task correctly. Here is
how I see the implementation.
It will consist of the following pars:
- Test suite
- write templates for all types of template constructions:
- variables
- filters
- inherited templates
Hi,
My name is Oleksii Oleksenko, I'm a master student in Distributed System
Engineering at TU Dresden (Germany) and I want to participate in GSoC by
contributing into your project. I decided to apply to Django because Python
is my main and favorite programming language and I work mostly in the
12 matches
Mail list logo