GeezerVison

There are more options available to make deepcopy faster (see #91610 (comment)).

If we want to make deepcopy faster, I believe we should gather enough support so a core dev can review a C (or rust?) implementation. With a C implementation we have much larger performance gains (see https://github.com/percolab/copium for example).

I don't think a pure-Python tweak and a C/Rust deepcopy are opposing directions — they optimize different ends and can coexist. This change helps every build today with no extension to compile and no new maintenance surface, and it doesn't block or complicate a future C implementation; if one lands, this just becomes a small fast path that the C version supersedes.

I've also reduced this PR to the minimal change: a 3-way benchmark (base / inline-check-with-local-capture / inline-check-using-the-global) showed the entire speedup comes from the inlined type(...) in _atomic_types check, and the local-variable capture added nothing measurable, so I dropped it.

@Bobronium is right: the first version ran type() twice for every non-atomic element, once in the inline guard and once again inside deepcopy(). I measured the cost, tested three designs to address it, and picked the one that is fastest with the smallest regression.

Method

I compared each version of Lib/copy.py on the same built interpreter (3.16.0a0), loaded as the copy module, driven by pyperf (1 warmup + 3 values × 20 processes, 5 independent runs per version). Coefficient of variation across the 5 run-means stayed at or below 1.1% on every workload, so the gaps below are real rather than jitter. Workloads span all-atomic to all-non-atomic, with the worst case for the regression (empties: a list of 2000 [], non-atomic elements with no atomic data to amortize the check against).

Options tested

1. Inline guard (the first push): a if type(a) in _atomic_types else deepcopy(a, memo) in each copier. Skips the call for atomic elements but types non-atomic elements twice.
2. Inline guard + local capture: same, with type and _atomic_types bound to locals/default args in each copier.
3. Single type(): split deepcopy() into a thin entry plus an internal _deepcopy_fallback(x, memo, cls) that takes the already-computed class. Each element is typed once whether or not it is atomic.

Results (speedup vs main, higher is better)

How I chose

Option 2 (local capture) buys about 3% on the atomic cases but leaves the worst case at 0.96x, since it removes a global lookup, not the second type() call. It does not address the review. (I also tried option 3 plus local capture; it came out slightly worse than plain option 3 on the worst case and the realistic case, so the extra binding was not worth it.)

Option 3 wins on every axis that matters: it has the smallest regression (0.98x vs 0.96x, halving the worst-case loss), it is fastest on the realistic mixed workload (+18%), and it keeps the atomic gains (1.40x and 2.19x). The regression that remains is narrow: it needs non-atomic elements holding no atomic data anywhere in their subtree. Any atomic leaf tips the structure positive, which is why nested dict lands at +18%.

The branch now uses option 3, applied to the list, tuple, dict and frozendict copiers. test_copy (83 tests) and test_pickle pass. Raw pyperf JSON for all runs is available if anyone wants to verify.

This is a significant code complication. I don't think a 20% gain in microbenchmarks is worth it.

Considering this is used quite often, the impact can be big. I think a 30-line extra is worth it.

I concur with @serhiy-storchaka, this is too much complexity for the gain.

Alright. 22% for 22 lines IMHO is not too much but I digress.