On Wed, Oct 10, 2012 at 6:29 PM, Florian Apolloner <f.apollo...@gmail.com>wrote:
> That said, if you really think Django's urlresolver is to slow, go ahead, > profile it and improve it, we certainly won't say no to speed improvements… > That's not really fair. Django core *will* say no to speed improvements if they necessitate any backwards incompatibilities, which due to early design decisions they often will. The main reason Django's url resolver is slow is that it was designed to allow some very flexible patterns. Just like middleware is slow because it is globally configured and called on every request. And the template language is slow because it allows arbitrary textual replacements and has a flexible import system that defeats compilation. Django has committed itself to backwards compatibility, which means it tends to get larger and heavier over time, and decisions that were made long ago have lasting impact. Speed is a real feature even in python, but Django has very consciously chosen to prioritize other things. I consider it a valid argument to say, "Django cares more about developer productivity and backwards compatibility than framework speed," but "Fix it yourself" is a hackneyed open-source truism, and "Speed doesn't matter" is more or less self-evidently false -- especially to someone evaluating frameworks, who may not yet have a strong opinion on what features are game-changers for his application. Best, Alex Ogier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
