Don't know whether this is relevant or not but the Python Software Foundation has just decided to establish a facility that allows speed comparison of different Python releases. The thinking behind this is (at least) twofold:
1) People will more easily be able to determine which is the best Python implementation for them to use on their specific problems, and 2) Developers will be able to see relatively easily whether their changes make a positive or negative difference to performance, which /might/ help eliminate the performance sawtoooth (gets worse with a major release and then minor releases incre,entally improve it). I don't know whether we can share our shiny new hardware with anyone else, though ;-) regards Stefe On Sat, Apr 23, 2011 at 1:19 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Fri, Apr 22, 2011 at 9:22 PM, Shawn Milochik <sh...@milochik.com> > wrote: > >> > >> This was mentioned in Eric Florenzano's talk at DjangoCon 2010. Each > >> version has gotten slower. > >> > >> I haven't heard anything about the cause or plans to fix this, though. > >> If you've got a good test suite you can always use tools like Python's > >> profile module to track down slowdowns in your Django code and > >> contribute that knowledge to the developers' list. > >> > > On Sat, Apr 23, 2011 at 11:26 AM, Peter Portante > <peter.a.porta...@gmail.com> wrote: > > Is there a plan in place to address this? > > No - there isn't a plan to address this, because it isn't clear what "this" > is. > > While it is known that there has been a slowdown between versions, > that slowdown has been accompanied by a massive increase in > functionality -- for example, the 1.1->1.2 transition introduced > support for multiple databases. To the best of my knowledge, the > performance slowdown highlighted by Eric at Djangocon was relatively > small - 5-10%, not on the order of 30-50% slowdown. This matches with > my personal experience of upgrading. > > There are two performance issues in database operations that I'm aware > of that people commonly point to. > > Firstly -- deep cloning of query sets. Cloning a queryset is an > expensive operation, and if you are making extensive use of operations > that clone (e.g., very long chains of complex filters) you may see > performance issues. This isn't something that can be easily avoided -- > in order to preserve the API guarantees of a query set, deep cloning > is required. > > Secondly, the backwards compatibility infrastructure introduced in > order to support multiple databases. In order to guarantee backwards > compatibility, the value preparation methods on fields needed to use > some moderately expensive introspection methods. However because these > methods were introduced for 1.2, and we're currently preparing 1.4, > these introspection methods have just been removed from trunk. > > Beyond these two issues -- we're always interested in improving > performance, so if you can identify a specific performance issue, > we're happy to look at it. The more evidence you can provide (profile > runs, sample queries that are observably slower, and so on), the > easier it will be to address these problems. > > Yours, > Russ Magee %-) > > -- > 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 > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
