#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):
A quick overview why I think we must get rid of the deepcopy and use clone
based approach instead:
1. It is hard to restrict deepcopy to absolute minimal amount of changes
while maintaining the property that the deepcopy actually does a proper
copy of the copied object, especially if we want to either do a full
deepcopy or return self.
2. deepcopy is expensive, even if the `__deepcopy__` was defined exactly
like .clone() for each object.
3. The current usage of deepcopy in for example sql/query.py doesn't
actually do a full clone of the object. Instead, the query.py deepcopy
does a clone, and the clone isn't actually a full clone of the original
object.
I must point out once again that the speed gains of clone based approach
are significant. It is possible that using .clone() instead of deepcopy
will introduce new bugs, but in the long run the clone based approach is
the right one to use.
--
Ticket URL: <https://code.djangoproject.com/ticket/16759#comment:32>
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.
