Re: URL dispatcher slow?

2012-10-10 Thread Alex Ogier 
On Wed, Oct 10, 2012 at 6:29 PM, Florian Apolloner 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.

Re: URL dispatcher slow?

2012-10-10 Thread 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). 

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@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.

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

2012-10-10 Thread Stephen Burrows 
Thanks, Florian. That clarifies things. I didn't realize collectstatic was 
using two backends, but it makes sense. And thanks for putting up with me 
not being up to speed on the IRC discussion.

On Tuesday, October 9, 2012 1:20:39 AM UTC-7, Florian Apolloner wrote:
>
> Hi Stephen,
>
> On Tuesday, October 9, 2012 7:28:43 AM UTC+2, Stephen Burrows wrote:
>>
>> I'm a little confused by the track the discussion took recently... my 
>> impression was that the solution would *not* be to change from 
>> last_modified to a checksum, or to add an additional checksum method. 
>> Instead, storage backeds could support a has_changed method, which could be 
>> overridden to provide last_modified checking *or* checksum comparisons - or 
>> any other method of checking whether a file has changed. This seems like a 
>> useful, easy-to-explain, very generic way to handle checking whether a file 
>> has changed.
>
>
> This would be one way to do it (we've also discussed that in IRC), but we 
> couldn't figure out any implementation that would actually be useable. To 
> make this work you'd need to have a function signature like "def 
> has_changed(file_name, other_thing)" whereas other_thing would be some 
> hash/modified_time whatever provided by the source storage. Now we are back 
> to the situation I described in my answer to Jeremy…
>
>  
>
>> And since what staticfiles actually cares about is whether the file has 
>> changed, it seems like it would make more 
>
> sense to use a method that checks whether the file has changed, rather 
>> than just checking the last modification date.
>
>
> Well staticfiles doesn't care, it's only collectstatic which cares to some 
> extend. So in my opinion the cleanest way (which means without coupling the 
> two needed storage backends together to strongly) is to provide your own 
> collectstatic command where you can do what you want with the checks (if 
> you have problems implementing that we'd happily move some code to extra 
> methods to make reusing collectstatic easier).
>  
>
>> Would I be correct in thinking that the main argument against this is API 
>> bloat, or is there something else that I'm not seeing?
>>
>
> I'd rather say: We don't see __any__ nice way to actually support 
> something which is generic enough the be useful. 
>
> 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/-/A7G6vLq58aYJ.
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.

Re: URL dispatcher slow?

2012-10-10 Thread Florian Apolloner 
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@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.

Re: URL dispatcher slow?

2012-10-10 Thread Daniel Sokolowski 
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@googlegroups.com 
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@googlegroups.com 
Subject: Re: URL dispatcher slow?

2012/10/10 Moonlight 

  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@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.

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@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.

Re: URL dispatcher slow?

2012-10-10 Thread Daniel Sokolowski 
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@googlegroups.com 
Subject: Re: URL dispatcher slow?

2012/10/10 Moonlight 

  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@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.

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@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.

Re: Redesign of djangoproject.com?

2012-10-10 Thread Damián Pérez 
I agree.

Very good Idea,

El sábado, 28 de abril de 2012 03:05:27 UTC-5, Russell Keith-Magee escribió:
>
> Hi Dana, 
>
> I completely agree. I've been trying to get a redesign of 
> djangoproject.com going for quite some time under the auspices of the 
> Django Foundation. As you can see from the lack of changes, you can see 
> that I haven't been particularly successful :-( 
>
> The fundamental problem is that we have plenty of coding talent at our 
> disposal, but not as much design talent. That's not to say that there 
> aren't many talented designers in our community -- there are -- it's just 
> that they're all very busy. We've approached several people in the Django 
> design community asking them to help out, and some have even made done some 
> initial work. However, redesign of a high-profile site like 
> djangoproject.com is a big job, and nobody has been able to spare the 
> time to bring the job to completion. 
>
> So - at this point I'm open to any offers. I want to avoid design by 
> committee -- ideally, I would like to pass this off to a single person (or 
> a small group) and give them complete control over design process. I'm not 
> completely sure how to organise who gets this role -- suggestions are 
> welcome. 
>
> If you (or anyone else) is interested, drop me a line and I can give you 
> the design brief we've been working with. 
>
> Yours, 
> Russ Magee %-) 
>
>
>
> On Saturday, 28 April 2012 at 3:22 PM, Dana Woodman wrote: 
>
> > So now that Django is being moved to Git/Github (which is awesome!), 
> maybe it would be a good time to think about a revamped home page for the 
> project ala djangoproject.com (http://djangoproject.com)? 
> > 
> > Obviously this is no small undertaking and would be potentially 
> contentions as to what would be the proper path, but I feel (and I don't 
> think I'm alone) that djangoproject.com (http://djangoproject.com) could 
> use a bit of a facelift. 
> > 
> > I have some idea of my own as to how this could be accomplished and I'm 
> sure there are a ton of others out there with great ideas as well. Maybe we 
> could open up some discussion on this idea? 
> > 
> > Forgive me if this has been proposed before as I'm new to the group! 
> > 
> > Cheers, 
> > Dana 
> > 
> > -- 
> > 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/-/g8ngEnVG_EsJ. 
> > To post to this group, send email to 
> > django-d...@googlegroups.com(mailto:
> django-d...@googlegroups.com ). 
> > To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com  (mailto:
> django-developers+unsubscr...@googlegroups.com ). 
> > 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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ksB1tZaOJY0J.
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.

Re: URL dispatcher slow?

2012-10-10 Thread Aymeric Augustin 
2012/10/10 Moonlight 

> 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@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.

URL dispatcher slow?

2012-10-10 Thread Moonlight 
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@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.

Re: Django performance vs others

2012-10-10 Thread Moonlight 
I think this  one 
explains how it works.

By the way, I had the curiosity to take a look at Python ML 
entrywhich
 is called "Fastest web framework" and I the Wheezy 
> framework . The cache 
> api- for 
> instance - is not something I would call well designed and useable :
>
> @response_cache(none_cache_profile)
> def change_price(request):
> ...
> with cache_factory() as cache
> dependency = CacheDependency('list_of_goods')
> dependency.delete(cache)
> return response
>
> Is it working code ? where does the returned response come from and how 
> does the 3 lines above can impact it ? 
> If you want to turn off the cache you have to change all that logical 
> code, not just the @decorator, right ? Seriously, dude.
>
>>

-- 
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/-/2upGTMGQEGQJ.
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.

Re: #13781: select_related and multiple inheritance

2012-10-10 Thread Tomas Ehrlich 
Works for me. I've just have to resolve two conflicts, new patch
submited, see https://code.djangoproject.com/ticket/13781#comment:16.

Cheers, 
 Tom

Dne Wed, 10 Oct 2012 01:47:38 -0700 (PDT)
Piotr Czachur  napsal(a):

> Hi!
> 
> Patch from ticket #13781 looks like a good candidate for review as it fixes 
> a few bugs in ORM.
> Could someone please take a look at it?
> 
> Cheers,
> Piotrek.
>

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

#13781: select_related and multiple inheritance

2012-10-10 Thread Piotr Czachur 
Hi!

Patch from ticket #13781 looks like a good candidate for review as it fixes 
a few bugs in ORM.
Could someone please take a look at it?

Cheers,
Piotrek.

-- 
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/-/pFywGnvLxrYJ.
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.