Re: Suggestion: a new "nature" field in Trac
On Feb 22, 11:22 am, Russell Keith-Magee wrote: > 2) Directing people who are inclined to be altruistic to the right place. For Firefox bugs, each patch can be flagged as follows: Request a review from anyone: review=? Request a review from someone specific: russellm: review? Russel hates the patch: russellm: review- Russel likes the patch: russellm: review+ Russel thinks Jannis is better place to review this: jezdez: review? This obviously doesn't cure the "we need more people reviewing patches" problem, but it does allow triagers to nudge the appropriate people to review certain patches. A long list of "review these patches" might be the motivation some people need. It may be argued that this just adds to the administrivia of tickets, but it is certainly effective for firefox. But that may be to the large number of contributors willing to do patch reviews. -- Martin -- 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.
Benchmarking change to query.get() #15361
Hi All, Background to this post is available at http://code.djangoproject.com/ticket/15361 I've created a better benchmark in order to test where the change in the above ticket causes a performance regression. These are the results of those tests. First of all, the results are based on query.get() on 2 Book objects, generated by the following code [1] I ran the following 2 benchmarks query_get [2] and query_get_multiple [3] on MySQL and sqlite. query_get is a simple get() using a unique indexed column and will return one object only. query_get_multiple is a get() on an non-indexed column, it will return 1284 objects. The benchmark results, as reported by djangobench [4] are as follows: sqlite: --- Running all benchmarks Control: Django 1.3 beta 1 (in django-control) Experiment: Django 1.3 beta 1 (in django-experiment) Running 'query_get' benchmark ... Min: 0.00 -> 0.00: incomparable (one result was zero) Avg: 0.000745 -> 0.000979: 1.3141x slower Significant (t=-5.900348) Stddev: 0.00263 -> 0.00297: 1.1318x larger (N = 1) Running 'query_get_multiple' benchmark ... Min: 0.02 -> 0.00: incomparable (one result was zero) Avg: 0.029883 -> 0.001072: 27.8759x faster Significant (t=482.259535) Stddev: 0.00511 -> 0.00309: 1.6519x smaller (N = 1) --- mysql --- Running all benchmarks Control: Django 1.3 beta 1 (in django-control) Experiment: Django 1.3 beta 1 (in django-experiment) Running 'query_get' benchmark ... Min: 0.00 -> 0.00: incomparable (one result was zero) Avg: 0.000810 -> 0.001039: 1.2827x slower Significant (t=-5.591014) Stddev: 0.00273 -> 0.00305: 1.1169x larger (N = 1) Running 'query_get_multiple' benchmark ... Min: 0.02 -> 0.00: incomparable (one result was zero) Avg: 0.028856 -> 0.001152: 25.0486x faster Significant (t=429.695948) Stddev: 0.00560 -> 0.00319: 1.7544x smaller (N = 1) --- As you can see, with 1 trials, the speed differences are significant (and repeatable) as are roughly as follows: query.get() on a unique indexed column runs 1.3x slower query.get() on an non-unique, non-index column runs 25-27x FASTER I've done some very quick tests to see how these gains/losses scale for various values of n objects: The speedup for the non-indexed columns is exponential to n. The slowdown for the indexed columns is roughly constant for all n. So there you have it, we have a small regression in performance for the most common case use, and a huge potential gain for the less used (and some would argue, badly designed) query. What do you think, is the gain worth the hit? Is it possible to have 2 different code paths depended on what column(s) the query is filtering on? -- Martin P.S Between each trial, djangobench will try and reload the initial_data.json fixture, which for 2 objects is very time consuming. If you want to reproduce the results yourself, I'd suggest creating a database with the objects already in it, instead of relying on fixtures. [1] object generation script -- http://pastebin.com/6JAJDA6f [2] query_get benchmark -- http://pastebin.com/qZBdvSie [3] query_get_multiple benchmark -- http://pastebin.com/iEYsfmd5 [4] djangobench project (Luke's fork) -- https://github.com/spookylukey/djangobench -- 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: Benchmarking change to query.get() #15361
On Feb 24, 11:40 pm, Russell Keith-Magee wrote: > Optimizing Django's retrieval code for the bad design > case strikes me as equally bad design. I say document this and leave > the code as is. Ok, I'll write a documentation patch for this for the optimisation section. Good job for catching this slowdown, Luke. I would never have thought of it. -- Martin -- 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: "needsinfo": resolution vs. triage stage
On Feb 25, 3:17 am, Gabriel Hurley wrote: > - May intimidate new contributors to see that their ticket was "closed". > - Doesn't discount the fact that there may be a valid issue here which we > don't want to forget about. I wouldn't underestimate either of these 2 points. The PHP core team "close" issues that need replies/more info, or simply haven't gained any attention after a month. Coming from a reporter of a few of those issues, I can say it is extremely offputting as it's (in PHP's case) almost impossible to get those tickets out of that state, even if more info has been supplied. Many valid bugs were shelved/forgotten for lack of interest. Trac also doesn't seem to search "closed" tickets, so you may have an increase in duplicate bugs being reported. Realise as a new dev, my vote doesn't carry much weight, but I would +1 triage stage for the reasons above. -- Martin -- 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.
#15575: MultipleObjectMixin.paginate_queryset always returns is_paginated=True, despite docs saying otherwise
http://code.djangoproject.com/ticket/15575 Should the patch fix the documentation to match tested behaviour (one passing test in generic_views specifically tests this case), or should the code be patched to meet the expectation of the documentation? -- Martin -- 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.
