This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Small optimization for PyDict_Merge()
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: barry, rhettinger, tim.peters
Priority: normal Keywords: patch

Created on 2005-05-11 18:02 by barry, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
dict-patch.txt barry, 2005-05-11 18:02
Messages (6)
msg48332 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2005-05-11 18:02
This patch avoids repeated PyDict_GetItem() calls when
'a' in PyDict_Merge() is known to be empty. 
Optimization found by Matt Messier.

This could also be applied to Python 2.5.
msg48333 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2005-05-12 14:45
Logged In: YES 
user_id=12800

Does changing the group mean you don't think this should be
applied to 2.4?  It doesn't change semantics at all.  (I'm
not necessarily disagreeing with you, but am just asking for
some justification in the issue tracker.)
msg48334 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2005-05-12 16:03
Logged In: YES 
user_id=31435

Well, in general we don't backport optimizations:  that 
something _could_ be made faster is rarely considered to 
be "a bug".  If, e.g., this was very much faster in 2.3 than in 
2.4, then _maybe_ it could be sold as a 2.4 bug.  Otherwise 
presumption favors that it's just one more of the literally 
thousands of speedups that could always be made.

In this case, it's not a pure win, so is especially dubious for a 
bugfix release:  it adds a test + taken-branch to the critical 
path whenever the function is called with a _non_-empty 
target dict.  So it slows what's probably the most common 
case a little, in order to speed a probably-rarer case.  Is that 
a net win or net loss?  Depends on the app, I suppose.

Did you try this in your app and _measure_ a net win?
msg48335 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2005-05-12 16:41
Logged In: YES 
user_id=80475

Right.  I marked it for 2.5 because optimizations usually do
not get backported.

With respect to Tim's comment about slowing the common case,
I don't see it.  The test is outside the inner loop.  The
variable that it sets helps short-circuit the inner-loop
tests.  All-in-all, it's a net win.

With respect to measurement, I would be surprised if the OP
could easily demonstrate a speed-up.  Grepping through
Objects and Modules shows zero calls to PyDict_Merge() where
the override argument is zero.   The idea looks sound, but
it looks like you're optimizing a case the doesn't occur in
practice.
msg48336 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2005-05-12 17:38
Logged In: YES 
user_id=12800

Thanks for the clarification.  It happens in our code, but I
can't say I've done much benchmarking.
msg48337 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2005-05-14 18:08
Logged In: YES 
user_id=80475

Applied as Objects/dictobject.c  2.165
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 41972
2005-05-11 18:02:31barrycreate