#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 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* stage: Accepted => Ready for checkin
Comment:
I've taken another look at this ticket and I am convinced this is the
right way to go. There are two reasons, in order of importance:
1. We are abusing the `__deepcopy__`, that is, we are making deep copies
which aren't actually equivalent to the original. (Example:
`sql.query.Query.__deepcopy__()`).
2. Performance. For the F() case (the original reason for this ticket)
there is a major improvement (order of magnitude improvements likely in
real-world usage). For the non-F() case we still have things like 50%
faster model.save() (on in-mem SQLite) and 50s away from 450s django-core
test suite speed.
This is somewhat scary issue, but on the other hand the benefits are
really nice... So, if nobody objects I will commit this one soon. The
branch at https://github.com/akaariai/django/compare/ticket_16759 contains
the commit candidate.
--
Ticket URL: <https://code.djangoproject.com/ticket/16759#comment:35>
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
