gh-154594: Fix deepcopy memo lookup when __deepcopy__ returns None - #154595
gh-154594: Fix deepcopy memo lookup when __deepcopy__ returns None#154595tonghuaroot wants to merge 3 commits into
Conversation
eendebakpt
left a comment
There was a problem hiding this comment.
Two small comments, but I am leaning more towards the approach suggested in the corresponding issue.
Addresses review: clearer, no sentinel, and the test treats memo as opaque.
|
Switched to Microbenchmark (5M lookups): |
Faster in both cases? Did you measure purely |
|
The earlier numbers included the surrounding statements. Measuring just the lookup, each returning the value (best of 5 runs of 10M): So |
|
Ok if the surrounding stuff was properly included, then that's good. This new comparison for "just the lookup" is not, it's missing the |
|
Anyway, I agree that misses are probably the common case, and I'm not surprised if full deepcopy timings are within noise either way, as deepcopy is rather slow. |
eendebakpt
left a comment
There was a problem hiding this comment.
Two small nits, but this looks good to me.
PR #138429 (gh-132657) replaced the memo-miss sentinel from
_nil = []toNonefor free-threading performance. ButNoneis a valid deepcopy result, somemo.get(d, None)can't distinguish "not found" from "found None". This skips memoization for None-valued results, causing redundant__deepcopy__calls.Fix: use a private
_MEMO_MISS = object()sentinel. Immortalized objects have no refcount contention, so the FT benefit is preserved.