Here's an issue to be aware of wrt template performance:
I noticed that one of my templates was getting really slow. I profiled
it and it seemed to spend lots of time calling the __str__ method of
one of my models. The method contains a query for a related object,
which slowed things down quite a bit.
The mystery was, why was __str__ called in the first place, since my
template never prints out instances of that particular models, but only
accesses its properties directly.
The root cause of the slowdown was an {% ifnotequal myobj None %} tag,
which causes a variable lookup failure since 'None' is not part of the
context. You can't compare None values this way in Django of course,
and I should have known that, and in this particular case changing the
condition to {% if myobj %} works just fine too; problem solved and
customer happy.
I was still left intrigued about the __str__ call, and with some
debugging I made the following observations:
The reason for the __str__ call lies in the default Model.__repr__
method (django/db/models/base.py:79 in Django r4269), which ends up
evaluating '%s' % self as a part of the string it builds.
Why was __repr__ called then?
It turns out that even though failed variable lookups in many cases
silently evaluate as empty strings in Django templates, exceptions are
raised and caught behind the scenes, and to generate some of the
exception messages calls to model methods are required. In my case the
__repr__ call was triggered in the resolve_variable function
(django/template/__init__.py:663 in r4269) when 'None' was not found in
the context. Actually, if I'm not mistaken, __repr__ is called
recursively for every object in the context tree!
So, to avoid template performance problems, one should make sure that:
- no unnecessary variable lookup failures occur
- model __str__ methods are lightweight
- or, alternatively, lightweight __repr__ methods are defined for
models
This kind of performance problems are tricky to profile and debug, so
some help from Django's side would be useful. Any ideas?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
