Hi Malcolm,

Thanks for the reply.  This issue is definitely seems to responsible
for a good chunk of the time it takes for django to return a response
in my app, about 70 ms to be precise.

Basically, I'm rendering a page which has a list of Template'd
objects, each of which inherits/extends from a base template.  This
means that in the course of a listing of, say, 25 things, I'm seeing
27 disk-hits/read/parse/tokenize (two for the page's own template, and
then one for each of the items, all of which inherit from the same
base template), which in total account for the 70 ms of CPU time.
Perhaps this is a "pathological" use of the templating engine, but
seeing as I'd like each item in the listing to be one of a variety of
object types (with some shared UI components), it seemed reasonable to
use template inheritance.

Having made a bit of a forray into the source code, the behavior I'm
looking for seems possible by changing the return call at the end of
ExtendsNode.get_parent from
            return get_template_from_string(source, origin, parent)
to
            self.parent_name = get_template_from_string(source,
origin, parent)
            return self.parent_name
This seems to make everything down the line render happily, given that
the case of self.parent_name being a Template is handled already
properly, but, of course, I can't tell if it will instead break
features that I'm not currently using.  It cuts out the 70 ms lag, at
least.

Regards,
Chris

On May 16, 2:52 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-05-16 at 21:27 +0000, Chris Slowe wrote:
> > I'm working on a project which is making rather copious use of extends
> > blocks, and I've noticed that every time an extends block is executed,
> > django seems to hit the file system, reads the file, and compiles the
> > parent template.  This behavior seems to be independent of whether
> > that particular parent template has been seen and compiled before.
>
> > I've traced the problem to ExtendsNode in loader_tags.py, where
> > get_parent is called when render is executed.  It seems like the
> > resulting rendered parent Template object is never cached, so
> > subsequent hits to render end up reloading the template from file
> > again.
>
> Is this behaviour a critical slowdown in the performance of your
> application?
>
> There are many micro optimisations that are possible in the template
> system (including caching pre-compiled templates), but the experience
> from the original developers was that they simply weren't necessary. It
> isn't a huge performance hit, in general.
>
> If you have performance numbers that show it really is a major component
> of the time budget for a request on templates that are "reasonable" (not
> pathological cases), that would be interesting to see so that we could
> look at what might be necessary.
>
> Regards,
> Malcolm


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to