#16759: Expensive sql.Query cloning
-------------------------------------+-------------------------------------
     Reporter:  Suor                 |                    Owner:  Suor
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  1.3
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:  orm performance      |      Needs documentation:  0
  cloning                            |  Patch needs improvement:  0
    Has patch:  1                    |                    UI/UX:  0
  Needs tests:  0                    |
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by akaariai):

 An up-to-date patch can be found from
 [https://github.com/akaariai/django/compare/ticket_16759].

 Some speed measurements using django-bench: nearly all of the query_*
 tests are around 20% faster (all except the ones testing large bulk
 operation speeds). The qs_filter_chaining is 3x faster.
 query_complex_filter is 1.5x faster.

 A test case used previously in this ticket:
 {{{
 10000x
 SomeModel.objects.filter(pk=F('pk')+1).all()
 }}}
 5x faster.

 Django's tests suite on sqlite: 10% faster (on an extensive one-iteration
 benchmark).

 The cloning speed isn't just a testing artefact. Reports for 200ms+
 queryset creation times for a single page load have been reported (can't
 find these just now, if references are needed, I can dig them from Trac).
 The Django ORM uses roughly 4x the time for generating SQL for simple
 "SELECT ... WHERE pk = x" query compared to execution of that query. One
 large part of this time is queryset cloning speed. In short, the speed
 problem is real.

 Note that fixing the `__deepcopy__` would make the F() case above faster,
 but most of the other speedups are not about the F() case - they are about
 the general slower speed of `__deepcopy__` compared to special tailored
 .clone() methods.

 Add in that the `__deepcopy__` methods Django uses aren't using good
 coding practices (they are not doing real deepcopies) and I think we have
 pretty convincing evidence that we really do want this approach.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/16759#comment:33>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to