#15283 closed (fixed)
A performance imporvement for QuerySet
Reported by: | lanyjie | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.2 |
Severity: | Keywords: | QuerySet performance | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Since the len method of class QuerySet is called quite frequently (for example, as p art of list(qs), we make some effort here to be as efficient as possible whilst not messing up any existing iterators against the QuerySet.
In the implementation of that method, I noticed a performance improvement, which is very simple to do. The last three lines of code was:
elif self._iter: self._result_cache.extend(list(self._iter)) return len(self._result_cache)
which involves the creation of a list to pass as an argument to the extend() method. Clearly this is not necessary as the extend() method takes an iterable, and self._iter is already iterable, so that can be simplified without creating the list, which should result in improved performance both in speed and in memory use. Here is the improved code:
elif self._iter: self._result_cache.extend(self._iter) return len(self._result_cache)
Change History (6)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 14 years ago
milestone: | → 1.3 |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Like Alex says, this obviously can't be worse, it's a one line change, and the existing test suite should be exercising this pretty hard. I've run it through the full test suite, and it doesn't break anything (not that I would expect that it would), so I'm gonna call this RFC.
This looks fine, do you have any actual performance numbers from this, or is it just a case of "it obviously can't be worse".