#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: Ready for
Keywords: orm performance | checkin
cloning | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
I have a completely different approach to this. The idea is simply to
define .clone() method for the where class (actually for utils/tree.py -
Node).
My test cases are:
{{{
# Case 1
qs = User.objects.all()
for i in range(0, 1000):
qs = qs._clone()
# Case 2
qs = User.objects.filter(pk=1).filter(pk=2).filter(pk=3)
for i in range(0, 1000):
qs = qs._clone()
}}}
The results are quite encouraging. For test case 1 the timing went from
0.163 -> 0.127s (about 25% speedup), and for test case 2 the timing went
from 0.501 -> 0.162, or more than 3x faster.
Patch attached, passes all tests. There is some attempt at making this
backwards-compatible in case the qs.query.where doesn't support clone().
--
Ticket URL: <https://code.djangoproject.com/ticket/16759#comment:7>
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.
