Discussion:
URL dispatcher slow?
(too old to reply)
Moonlight
2012-10-10 06:52:35 UTC
Permalink
Here is an article comparing various URL dispatchers:

http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html

What cause django URL dispatcher that much... slow?
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/xJFGtYmJsBYJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Aymeric Augustin
2012-10-10 13:30:34 UTC
Permalink
Post by Moonlight
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
What cause django URL dispatcher that much... slow?
Django's URL dispatcher is more complex than others. It provides advances
features such as reversing, automatic i18n, and namespaces. Of course,
these come at the expense of speed.

Note that this benchmark doesn't test URL dispatchers; it tests full stack
requests. With Django's default settings, lots of convenient features such
as middleware are enabled. This is likely to skew the results.

It'd be interesting to analyze what parts of the URL resolver are slow. If
you really want to know what going on, go ahead and profile it. I'd be
interested in the results (even though Django's performance has absolutely
never been a problem for me).

As a side note, I read these benchmarks with a grain of salt. They're
developed by the author of wheezy.web and consistently show it as a clear
winner. Where's the line between testing and marketing?
--
Aymeric.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Daniel Sokolowski
2012-10-10 14:32:19 UTC
Permalink
The middlewares appear to be disabled and the test bypasses the template system too: https://bitbucket.org/akorn/helloworld/src/c3f2d44dfca7/02-routing/django/helloworld/settings.py?at=default but yes Aymeric is right that Django provides a lot of convenience by default. In my opinion I rather take convenience as speed has not been a issue to me, but one thing though is that these benchmarks are transparent enough to give them some validity.

From: Aymeric Augustin
Sent: Wednesday, October 10, 2012 9:30 AM
To: django-developers-/***@public.gmane.org
Subject: Re: URL dispatcher slow?

2012/10/10 Moonlight <moonlight_13_666-/***@public.gmane.org>

Here is an article comparing various URL dispatchers:

http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html

What cause django URL dispatcher that much... slow?

Django's URL dispatcher is more complex than others. It provides advances features such as reversing, automatic i18n, and namespaces. Of course, these come at the expense of speed.

Note that this benchmark doesn't test URL dispatchers; it tests full stack requests. With Django's default settings, lots of convenient features such as middleware are enabled. This is likely to skew the results.

It'd be interesting to analyze what parts of the URL resolver are slow. If you really want to know what going on, go ahead and profile it. I'd be interested in the results (even though Django's performance has absolutely never been a problem for me).

As a side note, I read these benchmarks with a grain of salt. They're developed by the author of wheezy.web and consistently show it as a clear winner. Where's the line between testing and marketing?
--
Aymeric.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Daniel Sokolowski
http://webdesign.danols.com/
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Daniel Sokolowski
2012-10-10 14:42:14 UTC
Permalink
Yes, wheezy.web is much more bare metal compared to Django : http://packages.python.org/wheezy.web/tutorial.html

From: Daniel Sokolowski
Sent: Wednesday, October 10, 2012 10:32 AM
To: django-developers-/***@public.gmane.org
Subject: Re: URL dispatcher slow?

The middlewares appear to be disabled and the test bypasses the template system too: https://bitbucket.org/akorn/helloworld/src/c3f2d44dfca7/02-routing/django/helloworld/settings.py?at=default but yes Aymeric is right that Django provides a lot of convenience by default. In my opinion I rather take convenience as speed has not been a issue to me, but one thing though is that these benchmarks are transparent enough to give them some validity.

From: Aymeric Augustin
Sent: Wednesday, October 10, 2012 9:30 AM
To: django-developers-/***@public.gmane.org
Subject: Re: URL dispatcher slow?

2012/10/10 Moonlight <moonlight_13_666-/***@public.gmane.org>

Here is an article comparing various URL dispatchers:

http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html

What cause django URL dispatcher that much... slow?

Django's URL dispatcher is more complex than others. It provides advances features such as reversing, automatic i18n, and namespaces. Of course, these come at the expense of speed.

Note that this benchmark doesn't test URL dispatchers; it tests full stack requests. With Django's default settings, lots of convenient features such as middleware are enabled. This is likely to skew the results.

It'd be interesting to analyze what parts of the URL resolver are slow. If you really want to know what going on, go ahead and profile it. I'd be interested in the results (even though Django's performance has absolutely never been a problem for me).

As a side note, I read these benchmarks with a grain of salt. They're developed by the author of wheezy.web and consistently show it as a clear winner. Where's the line between testing and marketing?
--
Aymeric.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Daniel Sokolowski
http://webdesign.danols.com/
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Florian Apolloner
2012-10-10 22:29:05 UTC
Permalink
Oh cmon,

please stop playing a socket puppet for the wheezy.web author. A web
framework consists of more than just a win in speed (an the author of
wheezy.web can argue whatever he wants that "basic" stuff stuff should be
fast) -- if we were looking for speed we wouldn't use python at all
(period). The goal is to be fast enough and be able to scale out
horizontally, everything else is not really interesting in the case of web
development. While I won't deny that Django isn't the fastest framework out
there it certainly gets it's job done more than good enough and that's all
it matters. I don't know what your goal is, but please stop posting such
meaningless comparisons on django-dev…

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…

Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/DgNcKfL2AeUJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Yo-Yo Ma
2012-10-11 06:02:19 UTC
Permalink
Why does every conversation about Django's performance met with "GTFO we don't care"? (that was a rhetorical question :). I'd venture to guess that most "It's fast enough for me!" responses are predicated on experiences that can be likened to personal blog development, rather than large scale, 10+ server deployments (e.g., Disqus, et al).

If you had great abs, nice pecs, ripped legs, a nice deltoids, and 4" circumference biceps, you'd *probably* start to care when people said, "hey, what about those biceps...", no?

Are CPUs, RAM, and electricity free? (that too was a rhetorical question :)

Django is an *epic* (not in the literal sense :) framework, which offers a tremendous amount of functionality with nary an inkling of logical restraint. You can accomplish basically anything with Django without running into arbitrary limitations (e.g., have a gander at the limitations in most frameworks' URL dispatchers, just as a relevant example). To shorten this, from a features / ease of use standpoint, Django is just plain awesome.

BUT... Django is NOT that fast.

1) Django templates are unbearably slow (doesn't matter for a blog or something simple, but try something with lots of inline model formsets in a page and quite a few includes, and before you know it, you're wasting a decent percentage of your CPU on templates).

2) URL dispatching

3) Middleware is applied liberally (vs the a la carté, more efficient decorator approach to AOS)

The list goes on. What is the harm in discussing the weak points of Django? Performance is probably the only major weak point in Django right now (aside from the lack of schema migration in core, which is coming soon anyway).

I have no solution or patches in my pocket, but I can say with absolute certainty that performance will never, ever get better when discourse is in a monologue format.

That's all.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uZ9r1EtZnj4J.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Florian Apolloner
2012-10-11 07:13:02 UTC
Permalink
Hi,

I won't answer your rheotircal questions ;)
Post by Yo-Yo Ma
BUT... Django is NOT that fast.
We do know that (you know that and probably everyone else too) and I
already said in my post that Django isn't the fastest framework out there.

The list goes on. What is the harm in discussing the weak points of Django?
Post by Yo-Yo Ma
Performance is probably the only major weak point in Django right now
(aside from the lack of schema migration in core, which is coming soon
anyway).
There is no harm in discussing weak points in Django, we do it all the
time. I just don't think that copy pasting a link (and that more than once)
to a benchmark which is (imo) just there as a marketing strategy for
another framework (note: I am not saying the benchmarks are a fake, I am
just saying they probably aren't representive) adds real value to the
discussion.

I have no solution or patches in my pocket, but I can say with absolute
Post by Yo-Yo Ma
certainty that performance will never, ever get better when discourse is in
a monologue format.
I agree to some extend, but I think you shouldn't forget that many core
devs use Django on somewhat large-scale deployments (read: definetely way
over a blog) and performance issues are fixed as needed. But yes, as you
said stuff like templates are probably slower than they should be :/

Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/iVOJwI_v07kJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Yo-Yo Ma
2012-10-11 13:23:01 UTC
Permalink
I only now realized that this thread had started in a bit of a trolling fashion, and that there was a similar thread this week. That helps to explain the slightly more defensive stance.

Django can survive (and thrive) just fine in its current, reasonably performant state, but performance should have a priority, rather than being in a sort of "its fine as-is" stasis.

Benchmarks like the ones posted aren't that helpful, but it doesn't change the fact that there tends to be an anti-performance sentiment in this group. When you look at the latest Python 3.3.x release, you see that there are many performance improvements that are clearly not due to incidental changes. I'm merely suggesting that an initiative to better the performance of Django, perhaps by benchmarking to find some of the weakest points, determining the lowest hanging fruit, and creating tickets in trac for them. I would love to help optimize any given part of Django and submit a patch, but not if I'm afraid that it will never be applied and/or the ticket will be marked as "works for me", etc. Help give us who care about performance the most a real chance to make some improvements.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/bxfyOKgoRogJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Russell Keith-Magee
2012-10-11 08:20:13 UTC
Permalink
Post by Yo-Yo Ma
Why does every conversation about Django's performance met with "GTFO we don't care"? (that was a rhetorical question :).
Ok - If this is where the conversation is starting, it's going to go
downhill *very* fast.

Consider this a warning to *everyone* on this thread: we expect *all*
participants to maintain a civil and professional tone. Anyone
engaging in ad hominem attacks, straw man arguments, or any other sort
of offensive behaviour will be banned from posting. I'm not directing
this at anyone in particular - yet. But this is the second thread in a
week that has started down this path, and I want to make the rules
*absolutely* clear before anything gets out of control.

Back to the topic at hand:

We are interested in any concrete proposal that serves to improve
Django's performance.

However, we have no interest in optimisations for the sake of beating
some arbitrary benchmark score.

In addition, any claim that Django is "too slow" for practical
purposes is *demonstrably* false. There are *thousands* of sites in
production that are quite happily using Django. Many of them are
*very* large sites, serving *enormous* amounts of traffic. So, let's
dispense with the hyperbole that implies Django performance is so bad
it is only suitable for toy sites.

That said - could Django be faster? Sure. *Anything* can be improved.

So, if you've got a suggestion, make it. If you think URL resolving is
the source of the problem, propose a way to improve the speed of URL
resolvers. If you think the template language is the problem, propose
a fix.

And don't just say "Why are Django's URL resolvers slow?". Do some
profiling, and come back with an analysis of where the time is being
spent and/or wasted. Come up with a proposal for how Django's URL
resolvers could be made pluggable so that you can swap in a faster
resolver as an option.

We'll happily discuss concrete suggestions. We won't engage in fishing
expeditions.

Yours,
Russ Magee %-)
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ptone
2012-10-11 16:45:18 UTC
Permalink
Post by Russell Keith-Magee
That said - could Django be faster? Sure. *Anything* can be improved.
So, if you've got a suggestion, make it. If you think URL resolving is
the source of the problem, propose a way to improve the speed of URL
resolvers. If you think the template language is the problem, propose
a fix.
To do my part to increase the signal:noise.

I'll point out that just as writing a failing test is a great way to
augment a bug report - contributing or improving a benchmark for:

https://github.com/jacobian/djangobench

would be a good way to contribute to a discussion around a particular
performance improvement you're interested in seeing happen.

-Preston
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/kI7jNl7gYwEJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Sean Bleier
2012-10-11 17:03:17 UTC
Permalink
JKM, I'm wondering if it would benefit the community to house
djangobench under https://github.com/django to give it more
visibility. Just a thought.
Post by ptone
Post by Russell Keith-Magee
That said - could Django be faster? Sure. *Anything* can be improved.
So, if you've got a suggestion, make it. If you think URL resolving is
the source of the problem, propose a way to improve the speed of URL
resolvers. If you think the template language is the problem, propose
a fix.
To do my part to increase the signal:noise.
I'll point out that just as writing a failing test is a great way to augment
https://github.com/jacobian/djangobench
would be a good way to contribute to a discussion around a particular
performance improvement you're interested in seeing happen.
-Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/kI7jNl7gYwEJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Łukasz Rekucki
2012-10-11 21:58:52 UTC
Permalink
Post by Russell Keith-Magee
And don't just say "Why are Django's URL resolvers slow?". Do some
profiling, and come back with an analysis of where the time is being
spent and/or wasted.
FWIW, here's a link to a cProfile result for the mentioned
benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows
that we're calling get_language() 1.5mln times (read: for every
pattern), so that's definitely going to slow down things.

I'll try running the same with 1.3 and maybe 1.4 without the locale
mixin and post if I find anything interesting.

[1]: https://gist.github.com/3875701
--
Łukasz Rekucki
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Moonlight
2012-10-12 08:50:47 UTC
Permalink
Post by Łukasz Rekucki
FWIW, here's a link to a cProfile result for the mentioned
benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows
that we're calling get_language() 1.5mln times (read: for every
pattern), so that's definitely going to slow down things.
Happy to see we moved it a bit forward! Well done!
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ZnKPiKqj-tgJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Tom Evans
2012-10-12 09:47:43 UTC
Permalink
Post by Łukasz Rekucki
Post by Russell Keith-Magee
And don't just say "Why are Django's URL resolvers slow?". Do some
profiling, and come back with an analysis of where the time is being
spent and/or wasted.
FWIW, here's a link to a cProfile result for the mentioned
benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows
that we're calling get_language() 1.5mln times (read: for every
pattern), so that's definitely going to slow down things.
I'll try running the same with 1.3 and maybe 1.4 without the locale
mixin and post if I find anything interesting.
[1]: https://gist.github.com/3875701
It definitely doesn't help; ideally language code should be calculated
once per call to resolve, and the same value used throughout.
Hard-coding a value of 'en' for language code in
LocaleRegexProvider.regex gives an idea of what gains would be:

Stock django:

static[0] msec rps tcalls funcs
django 1583 6318 143 69

static[-1] msec rps tcalls funcs
django 20879 479 1934 70


Hard coded 'en' in LocaleRegexProvider.regex:

static[0] msec rps tcalls funcs
django 1424 7023 133 67

static[-1] msec rps tcalls funcs
django 4972 2011 929 68

static[0] represents tests matching the first URL in the urlconf,
static[-1] represents tests matching the approximately 100th URL in
the urlconf.

Cheers

Tom
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Moonlight
2012-10-16 10:52:43 UTC
Permalink
static[0]

138017 function calls in 0.818 seconds

Ordered by: internal time
List reduced from 79 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
1000 0.062 0.000 0.490 0.000 base.py:72(get_response)
2000 0.047 0.000 0.129 0.000 base.py:240(get_script_name)
1000 0.042 0.000 0.758 0.001 wsgi.py:210(__call__)
1000 0.040 0.000 0.247 0.000 urlresolvers.py:293(resolve)
1000 0.039 0.000 0.136 0.000 wsgi.py:129(__init__)
2000 0.031 0.000 0.052 0.000
trans_real.py:212(get_language)
7000 0.031 0.000 0.044 0.000 functional.py:182(inner)
3000 0.029 0.000 0.088 0.000 encoding.py:54(force_unicode)
14002 0.029 0.000 0.029 0.000 {isinstance}
1000 0.027 0.000 0.081 0.000 __init__.py:564(__init__)


static[-1]

1929017 function calls in 10.654 seconds

Ordered by: internal time
List reduced from 80 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
201000 2.998 0.000 4.928 0.000
trans_real.py:212(get_language)
200000 1.288 0.000 8.378 0.000 urlresolvers.py:195(resolve)
1000 1.175 0.001 9.973 0.010 urlresolvers.py:293(resolve)
408000 1.085 0.000 1.085 0.000 {getattr}
206000 0.879 0.000 1.231 0.000 functional.py:182(inner)
201000 0.878 0.000 6.577 0.000 urlresolvers.py:153(regex)
201000 0.755 0.000 5.682 0.000 __init__.py:128(get_language)
201000 0.547 0.000 0.547 0.000 {method 'search' of
'_sre.SRE_Pattern' objects}
199000 0.290 0.000 0.290 0.000 {method 'append' of 'list'
objects}
1000 0.094 0.000 10.272 0.010 base.py:72(get_response)


dynamic[0]

3745017 function calls in 20.459 seconds

Ordered by: internal time
List reduced from 80 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
402000 6.006 0.000 9.866 0.000
trans_real.py:212(get_language)
401000 2.528 0.000 16.700 0.000 urlresolvers.py:195(resolve)
1000 2.301 0.002 19.733 0.020 urlresolvers.py:293(resolve)
810000 2.162 0.000 2.162 0.000 {getattr}
402000 1.735 0.000 13.107 0.000 urlresolvers.py:153(regex)
407000 1.731 0.000 2.424 0.000 functional.py:182(inner)
402000 1.489 0.000 11.355 0.000 __init__.py:128(get_language)
402000 1.098 0.000 1.098 0.000 {method 'search' of
'_sre.SRE_Pattern' objects}
400000 0.571 0.000 0.571 0.000 {method 'append' of 'list'
objects}
1000 0.137 0.000 20.076 0.020 base.py:72(get_response)


dynamic[-1]

3916017 function calls in 29.633 seconds

Ordered by: internal time
List reduced from 80 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
421000 8.650 0.000 14.267 0.000
trans_real.py:212(get_language)
420000 3.693 0.000 24.279 0.000 urlresolvers.py:195(resolve)
1000 3.299 0.003 28.606 0.029 urlresolvers.py:293(resolve)
848000 3.112 0.000 3.112 0.000 {getattr}
426000 2.552 0.000 3.592 0.000 functional.py:182(inner)
421000 2.527 0.000 18.993 0.000 urlresolvers.py:153(regex)
421000 2.176 0.000 16.443 0.000 __init__.py:128(get_language)
421000 1.639 0.000 1.639 0.000 {method 'search' of
'_sre.SRE_Pattern' objects}
419000 0.805 0.000 0.805 0.000 {method 'append' of 'list'
objects}
1000 0.211 0.000 29.103 0.029 base.py:72(get_response)


seo[0]

1941017 function calls in 14.737 seconds

Ordered by: internal time
List reduced from 80 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
202000 4.162 0.000 6.855 0.000
trans_real.py:212(get_language)
201000 1.787 0.000 11.599 0.000 urlresolvers.py:195(resolve)
1000 1.594 0.002 13.797 0.014 urlresolvers.py:293(resolve)
410000 1.497 0.000 1.497 0.000 {getattr}
207000 1.243 0.000 1.747 0.000 functional.py:182(inner)
202000 1.230 0.000 9.164 0.000 urlresolvers.py:153(regex)
202000 1.056 0.000 7.911 0.000 __init__.py:128(get_language)
202000 0.693 0.000 0.693 0.000 {method 'search' of
'_sre.SRE_Pattern' objects}
200000 0.402 0.000 0.402 0.000 {method 'append' of 'list'
objects}
1000 0.143 0.000 14.221 0.014 base.py:72(get_response)


seo[-1]

2022017 function calls in 15.401 seconds

Ordered by: internal time
List reduced from 80 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
211000 4.360 0.000 7.189 0.000
trans_real.py:212(get_language)
210000 1.872 0.000 12.135 0.000 urlresolvers.py:195(resolve)
1000 1.698 0.002 14.454 0.014 urlresolvers.py:293(resolve)
428000 1.565 0.000 1.565 0.000 {getattr}
216000 1.311 0.000 1.834 0.000 functional.py:182(inner)
211000 1.289 0.000 9.584 0.000 urlresolvers.py:153(regex)
211000 1.084 0.000 8.272 0.000 __init__.py:128(get_language)
211000 0.725 0.000 0.725 0.000 {method 'search' of
'_sre.SRE_Pattern' objects}
209000 0.414 0.000 0.414 0.000 {method 'append' of 'list'
objects}
1000 0.148 0.000 14.884 0.015 base.py:72(get_response)


missing

8865573 function calls (8775573 primitive calls) in 57.023 seconds

Ordered by: internal time
List reduced from 225 to 10 due to restriction <10>

ncalls tottime percall cumtime percall filename:lineno(function)
122000/62000 10.171 0.000 18.105 0.000 pprint.py:247(_safe_repr)
421000 8.741 0.000 14.432 0.000
trans_real.py:212(get_language)
420000 3.723 0.000 24.273 0.000 urlresolvers.py:195(resolve)
938000 3.385 0.000 3.385 0.000 {getattr}
1000 3.350 0.003 28.598 0.029 urlresolvers.py:293(resolve)
1405000 3.170 0.000 3.170 0.000 {method 'write' of
'cStringIO.StringO' objects}
443000 2.728 0.000 3.817 0.000 functional.py:182(inner)
1338000 2.570 0.000 2.570 0.000 {method 'isalpha' of 'str'
objects}
421000 2.560 0.000 19.159 0.000 urlresolvers.py:153(regex)
421000 2.141 0.000 16.573 0.000 __init__.py:128(get_language)
Post by Tom Evans
It definitely doesn't help; ideally language code should be calculated
once per call to resolve, and the same value used throughout.
Hard-coding a value of 'en' for language code in
static[0] msec rps tcalls funcs
django 1583 6318 143 69
static[-1] msec rps tcalls funcs
django 20879 479 1934 70
static[0] msec rps tcalls funcs
django 1424 7023 133 67
static[-1] msec rps tcalls funcs
django 4972 2011 929 68
static[0] represents tests matching the first URL in the urlconf,
static[-1] represents tests matching the approximately 100th URL in
the urlconf.
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/_U3JOtsVP58J.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Tom Evans
2012-10-11 08:58:09 UTC
Permalink
Post by Yo-Yo Ma
Why does every conversation about Django's performance met with "GTFO we don't care"? (that was a rhetorical question :). I'd venture to guess that most "It's fast enough for me!" responses are predicated on experiences that can be likened to personal blog development, rather than large scale, 10+ server deployments (e.g., Disqus, et al).
At $JOB, we used to write our websites in C++. No, really, we used to
write all our web apps as part of custom apache modules that used our
own C++ framework. If I compared our C++ url routing code against any
of those python stacks tested, it would absolutely murder them. Yet we
don't write new websites in C++ - why?

The expensive parts of a website are not routing requests, it is DB
queries and waiting to write responses to clients. When you look at it
like that, the speed of "grunt" parts of your framework is simply not
relevant. Django's template system is considerably faster than our
XSLT templates we used in C++ (that doesn't paint XSLT in a good
light).

So, the benchmarks are interesting. They tell us which stacks are
fully featured, and which stacks are very lightweight. Apart from
that, they don't tell us much at all - is Django's template engine
slow, or is it about right for the work it does? This benchmark
doesn't tell us that, it only says it is slower than a bare bones
template engine, which is unsurprising, and shouldn't be a cause for
concern.

Cheers

Tom
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Moonlight
2012-10-11 12:07:02 UTC
Permalink
Post by Tom Evans
So, the benchmarks are interesting. They tell us which stacks are
fully featured, and which stacks are very lightweight. Apart from
that, they don't tell us much at all - is Django's template engine
slow, or is it about right for the work it does? This benchmark
doesn't tell us that, it only says it is slower than a bare bones
template engine, which is unsurprising, and shouldn't be a cause for
concern.
It is sort of no sense. Django is fully featured and we do not care... some
other are fast because they are lightweight... tell me which 'full
featured' feature prevents it from become better. I guess for the #1
framework it is important to be leader... hmm... not sure what you mean by
'right for the work it does'... who needs a template that doesn't do what
you need?
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/YAcwku7WouYJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Kkk Kkk
2012-10-11 13:10:37 UTC
Permalink
somehow it went to wrong address... sorry, here it is.

----- Forwarded Message -----
This is why I disagree with your conjecture that because Django is
slower than another framework, therefore Django is slow. That is not
what is shown, only that the other frameworks do certain things
faster.
I think we have the same standpoint of view here. May be it is faster somewhere else... but where? If it is slower here and there... it is probaly just slow, isn't it? May be the word 'slow' is not correct... if the framework does more for me in URL dispatch I want to know what that more means... I know it can do reverse url but that feature is not used in url dispatch.
Open source is wonderful, because you are allowed the choice of
framework. You can choose full featured, and accept that those
features will cost time, or you can choose lightweight, and not use
those features. There is no magical mid-way point where you get all
the features and all the speed.
Agreed. We are free to talk about this and that is good. It would be better if someone also listen. If the difference between lightweight and full featured impacts performance that much I want to see which features cause that. Let itemize the list. Honesty I tried... but just can not related them to the facts faced.



________________________________
From: Tom Evans <tevans.uk-gM/Ye1E23mwN+***@public.gmane.org>
To: Moonlight <moonlight_13_666-/***@public.gmane.org>
Sent: Thursday, October 11, 2012 3:46 PM
Subject: Re: URL dispatcher slow?
Post by Tom Evans
So, the benchmarks are interesting. They tell us which stacks are
fully featured, and which stacks are very lightweight. Apart from
that, they don't tell us much at all - is Django's template engine
slow, or is it about right for the work it does? This benchmark
doesn't tell us that, it only says it is slower than a bare bones
template engine, which is unsurprising, and shouldn't be a cause for
concern.
It is sort of no sense. Django is fully featured and we do not care... some
other are fast because they are lightweight... tell me which 'full
featured'
feature prevents it from become better. I guess for the #1 framework it is
important to be leader... hmm... not sure what you mean by 'right for the
work it does'... who needs a template that doesn't do what you need?
You are absolutely right - personally, I do not care one iota how fast
Django routes requests. I know that it does it fast enough, and that
improving the speed of that tiny subsection of code is not going to
improve the performance of my web application. This part of code makes
up a disproportionally small part of the request cycle, even if it was
twice as fast, the overall improvement would be negligible.

This is why I disagree with your conjecture that because Django is
slower than another framework, therefore Django is slow. That is not
what is shown, only that the other frameworks do certain things
faster.
From your previous post, talking about
I definitely would appreciate if someone from core team I guess or in the community finally have a look there
Django's url resolver _is_ fast. It does a lot more work than the
other frameworks under test, which is why it is subjectively slower
than them in that test, but that is not relevant. It could be made
faster, if it stopped doing the useful features that we rely on to
build our projects.

Open source is wonderful, because you are allowed the choice of
framework. You can choose full featured, and accept that those
features will cost time, or you can choose lightweight, and not use
those features. There is no magical mid-way point where you get all
the features and all the speed.

Cheers

Tom
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Alex Ogier
2012-10-11 06:38:07 UTC
Permalink
Post by Florian Apolloner
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Moonlight
2012-10-11 11:50:58 UTC
Permalink
Well.... I am not that good to get it fixed it django... it quite easy get
lost there. But I definitely would appreciate if someone from core team I
guess or in the community finally have a look there...

That said, if you really think Django's urlresolver is to slow, go ahead,
Post by Florian Apolloner
profile it and improve it, we certainly won't say no to speed improvements…
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/CZfjypvjpPQJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Daniel Sokolowski
2012-10-11 13:52:03 UTC
Permalink
I absolutely agree with: if we were looking for speed we wouldn't use python at all (period).

From: Florian Apolloner
Sent: Wednesday, October 10, 2012 6:29 PM
To: django-developers-/***@public.gmane.org
Subject: Re: URL dispatcher slow?

Oh cmon,

please stop playing a socket puppet for the wheezy.web author. A web framework consists of more than just a win in speed (an the author of wheezy.web can argue whatever he wants that "basic" stuff stuff should be fast) -- if we were looking for speed we wouldn't use python at all (period). The goal is to be fast enough and be able to scale out horizontally, everything else is not really interesting in the case of web development. While I won't deny that Django isn't the fastest framework out there it certainly gets it's job done more than good enough and that's all it matters. I don't know what your goal is, but please stop posting such meaningless comparisons on django-dev…

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…

Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/DgNcKfL2AeUJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Daniel Sokolowski
http://webdesign.danols.com/
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Alex Gaynor
2012-10-11 14:01:06 UTC
Permalink
On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski <
Post by Daniel Sokolowski
I absolutely agree with: if we were looking for speed we wouldn't use
python at all (period).
Speak for yourself.

Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Daniel Sokolowski
2012-10-11 14:13:09 UTC
Permalink
Was that necessary? I am tuning out of this conversion, it is becoming hostile.
From: Alex Gaynor
Sent: Thursday, October 11, 2012 10:01 AM
To: django-developers-/***@public.gmane.org
Subject: Re: URL dispatcher slow?




On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski <daniel.sokolowski-***@public.gmane.org> wrote:

I absolutely agree with: if we were looking for speed we wouldn't use python at all (period).


Speak for yourself.

Alex
--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Michael
2012-10-11 14:19:28 UTC
Permalink
This conversation is getting nasty. Django's URL dispatcher is what it is.
If you can get the flexibility that the current URL dispatcher provides
while making it faster, I imagine everyone on this thread would be
impressed.

There is no reason to use Django's URL dispatcher. It is quite easy to map
a WSGI path to the view functions. Heck, you can even write your own URL
dispatcher and let us all see your method. Maybe it will get traction.

I have not seen performance bottlenecks on templates or URL dispatchers. My
systems tend to bail due to the database or IO first. So benchmarks are
great and something to keep an eye on while adding new features or making
changes, but I am not going to worry about the abstract performance of URL
Dispatchers until it is clear that it accounts for a clear problem in the
request/response cycle.

Other than that we are seeing problems that are not actually there and
nothing will ever get done.
Post by Alex Gaynor
On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski <
Post by Daniel Sokolowski
I absolutely agree with: if we were looking for speed we wouldn't use
python at all (period).
Speak for yourself.
Alex
--
"I disapprove of what you say, but I will defend to the death your right
to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Tom Evans
2012-10-11 13:53:55 UTC
Permalink
Post by Moonlight
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
What cause django URL dispatcher that much... slow?
Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.

In a normal django application, you do not start from fresh on each
request. This explains why the performance degradation from
"static[0]" to "static[-1] " - which is the difference between testing
the first url in the urlconf and the last url in the urlconf - is so
pathological, each time it is run Django is recompiling each and every
URL regexp in the urlconf (as well as _all_ other work django does at
server start).

This is testing something, but it is not testing django as a web
application, or as Django is intended to be run.

Cheers

Tom
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Aymeric Augustin
2012-10-11 15:35:20 UTC
Permalink
Post by Tom Evans
Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.
Hi Tom,

The performance gap was really huge, roughly two orders of magnitude.
I had a gut feeling that the implementation of the URL resolver couldn't
explain it fully. This makes much more sense.

So, thank you for checking the benchmark's source code!

(I have to admit that I was too lazy and didn't care enough to do it
myself.)
--
Aymeric.
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Marco Paolini
2012-10-11 16:19:00 UTC
Permalink
Received: by 10.216.45.81 with SMTP id o59mr42027web.74.1349972362279;
Thu, 11 Oct 2012 09:19:22 -0700 (PDT)
X-BeenThere: django-developers-/***@public.gmane.org
Received: by 10.180.90.134 with SMTP id bw6ls15894522wib.1.canary; Thu, 11 Oct
2012 09:19:03 -0700 (PDT)
Received: by 10.180.73.173 with SMTP id m13mr475382wiv.4.1349972343522;
Thu, 11 Oct 2012 09:19:03 -0700 (PDT)
Received: by 10.180.73.173 with SMTP id m13mr475381wiv.4.1349972343511;
Thu, 11 Oct 2012 09:19:03 -0700 (PDT)
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176])
by gmr-mx.google.com with ESMTPS id k11si2369215wiv.0.2012.10.11.09.19.03
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 11 Oct 2012 09:19:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of markopaolini-***@public.gmane.org designates 74.125.82.176 as permitted sender) client-ip=74.125.82.176;
Received: by mail-we0-f176.google.com with SMTP id z53so1093065wey.7
for <django-developers-/***@public.gmane.org>; Thu, 11 Oct 2012 09:19:03 -0700 (PDT)
Received: by 10.216.116.70 with SMTP id f48mr812658weh.162.1349972343370;
Thu, 11 Oct 2012 09:19:03 -0700 (PDT)
Received: from [192.168.28.10] (78-134-3-205.v4.ngi.it. [78.134.3.205])
by mx.google.com with ESMTPS id ei1sm9427941wid.7.2012.10.11.09.19.01
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 11 Oct 2012 09:19:02 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
In-Reply-To: <CAFHbX1K5o+463_ceibG0qkeE8Gi4strBKpA+TFPO=jE0WuV4yQ-JsoAwUIsXosN+***@public.gmane.org>
X-Original-Sender: markopaolini-***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
domain of markopaolini-***@public.gmane.org designates 74.125.82.176 as permitted
sender) smtp.mail=markopaolini-***@public.gmane.org; dkim=pass header.i=@gmail.com
Precedence: list
Mailing-list: list django-developers-/***@public.gmane.org; contact django-developers+owners-/***@public.gmane.org
List-ID: <django-developers.googlegroups.com>
X-Google-Group-Id: 1042074780459
List-Post: <http://groups.google.com/group/django-developers/post?hl=en_US>, <mailto:django-developers-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:django-developers+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/django-developers?hl=en_US>
Sender: django-developers-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:django-developers+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:googlegroups-manage+1042074780459+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.python.django.devel/36969>
Post by Tom Evans
Post by Moonlight
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
What cause django URL dispatcher that much... slow?
Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.
no, the wsgi handler is instatiated only once and outside the timeit call
--
markopaolini-***@public.gmane.org
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Tom Evans
2012-10-12 08:36:04 UTC
Permalink
Post by Tom Evans
Post by Moonlight
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
What cause django URL dispatcher that much... slow?
Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.
In a normal django application, you do not start from fresh on each
request. This explains why the performance degradation from
"static[0]" to "static[-1] " - which is the difference between testing
the first url in the urlconf and the last url in the urlconf - is so
pathological, each time it is run Django is recompiling each and every
URL regexp in the urlconf (as well as _all_ other work django does at
server start).
This is testing something, but it is not testing django as a web
application, or as Django is intended to be run.
Cheers
Tom
I was wrong, the WSGI app is initialized correctly just once.
Something pathological is happening with this test case, the
performance of the resolver looks decidedly dicey as number of
patterns grows.

Something for the weekend…

Tom
--
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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Continue reading on narkive:
Loading...