> On Thu, Aug 6, 2009 at 2:55 AM, Russell > Keith-Magee<[email protected]> wrote: >> As is noted in the ticket, one of the reasons that this wasn't done >> originally was that the performance boost wasn't seen as being that >> considerable. > > I suspect there'll be a goodly speedup even for the common case, since > what caching basically avoids here is the IO requirements of going to > the disk. Processors have gotten lots more powerful over the last five > years, but disk IO is just as slow.
I haven't done very extensive testing on projects other than my own, but at the very least these changes shouldn't slow anything down. What I'd really love to see, actually, is some empirical data from people testing these changes on their own apps. I was really surprised at the performance gains we saw, so I'd be interested in hearing if simpler apps see a noticeable improvement as well. > Finally, like Russ, I'm worried about the effect this will have on > existing template tags. Auditing code I have lying around, I see at > least a half-dozen tags that store state on self. I think it's even > figured into some docs and books. So figuring out *some* way of at the > very least easing that transition would help the pill go down quite a > bit. Yes, I agree that accommodating legacy tags is very important. Leaving caching off by default should make things easier on people -- they can choose to upgrade their existing code if and when they decide template caching is worthwhile. The addition of the "parser context" should also help. This feature should be well documented along with the risks associated with storing state on self (note that instances can store _some_ state if it doesn't change, like variable names and other arguments). The only dangerous things I found in the built-in template tags were block, extends, and cycle. Fixing block & extends was tough (there was some prior work here which helped a lot, so thanks to the folks who worked on that). But cycle was a pretty trivial change (two or three lines), and I suspect it's a more typical tag -- with the "parser context" available I think most tags can be made cache/thread-safe fairly easily. I thought about adding a ``data`` dictionary to template tags with each template render. This dictionary could be used in ``render`` to store state (so you could just stick stuff in self.data[key] and self.data would be set to something like context.parser_context[self]) but I decided that was a bit too magical and wasn't really a big improvement over explicitly using ``context.parser_context``. Russ, I totally agree that we need to be careful not to screw up the template tag stuff. The existing template-tag API is unchanged -- in fact there's no need to change anything at all unless you enable caching. The bit that probably needs the most attention & review are the block/extends changes. I spent a lot of time deciphering that code and I'm fairly confident that the patch duplicates the existing functionality, but it was rather complicated code and it's important we don't mess something up that's used by pretty much every Django app in the wild ;). Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
