This was a case where there was a tradeoff between correctness and
speed. Previously EmptyQuerySet (the class used by .none() internally)
wasn't a real QuerySet class. This caused a couple of problems
(subclassing and no error checking at least). Now .none() just generates
a WhereNode for the query that ensures no query is ran on execution and
no objects are returned when the queryset is iterated.
- Anssi
On 09/16/2013 04:54 AM, charettes wrote:
I guess it's related to a2396a4c8f[1] and #19184[2].
[1]
https://github.com/django/django/commit/a2396a4c8f2ccd7f91adee6d8c2e9c31f13f0e3f
[2] https://code.djangoproject.com/ticket/19184
Le dimanche 15 septembre 2013 20:05:43 UTC-4, Curtis Maloney a écrit :
So what's going on here:
Running 'query_none' benchmark ...
Min: 0.000044 -> 0.000262: 5.9674x slower
Avg: 0.000047 -> 0.000290: 6.1906x slower
Significant (t=-12.805744)
Stddev: 0.00001 -> 0.00013: 14.5148x larger (N = 50)
--
Curtis
On 15 September 2013 16:31, Anssi Kääriäinen <anssi.ka...@thl.fi
<javascript:>> wrote:
On Sunday, September 15, 2013 3:13:09 AM UTC+3, Curtis Maloney
wrote:
Hey, thanks for that!
It would be nice to have something that would chart this
over time... something like some people have set up for GCC.
I've never been able to get djangobench to give meaningful
results, otherwise I'd do it.
Mmm... perhaps I've just found a use for my odroid :)
I have a simple setup for generating graphs over time. Results
are something like this:
http://users.tkk.fi/~akaariai/djbench/model_save/
<http://users.tkk.fi/%7Eakaariai/djbench/model_save/>.
Unfortunately I haven't found the time to automate benchmarking.
When using djangobench it is extremely important to turn all
sorts of cpu speed throttling off. Power saving features will
cause random results. It seems the older your hardware is, the
better results you will get. Even then, if you forget to
disable cpu throttling you will get results like this:
http://users.tkk.fi/~akaariai/djbench/model_creation/
<http://users.tkk.fi/%7Eakaariai/djbench/model_creation/>
I managed to spot why form_create is 15x slower in average -
it is all about translation startup speed. A string that
wasn't translatable before now is, and I guess the first time
that string is translated will cause a huge spike in runtime.
Luckily the rest of iterations are about same as always. In
short, form_create was a false alarm. Or, see
http://users.tkk.fi/~akaariai/djbench/form_create/
<http://users.tkk.fi/%7Eakaariai/djbench/form_create/>
- Anssi
--
You received this message because you are subscribed to the
Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to django-develop...@googlegroups.com
<javascript:>.
To post to this group, send email to
django-d...@googlegroups.com <javascript:>.
Visit this group at
http://groups.google.com/group/django-developers
<http://groups.google.com/group/django-developers>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
