copy.copy and copy.deepcopy scale poorly with free-threading

[eendebakpt]

The copy.copy and copy.deepcopy operations running on different objects in different threads should be able to run independently. The scaling is not good: output of the ftscalingbench.py with added benchmarks:

Running benchmarks with 8 threads
shallow_copy               4.6x slower
deepcopy                   2.3x slower
object_cfunction           5.9x faster
cmodule_function           5.9x faster
object_lookup_special      5.5x faster
mult_constant              5.6x faster
generator                  4.9x faster
pymethod                   5.2x faster
pyfunction                 4.5x faster
module_function            5.0x faster
load_string_const          5.6x faster
load_tuple_const           5.9x faster
create_pyobject            2.3x faster
create_closure             7.1x faster
create_dict                3.3x faster
thread_local_read          3.3x faster

There are at least two reasons:

• The copy module uses module level variables in the copy.copy and copy.deepcopy methods.
• The _copy_atomic_types (and some similar data structures) is a set which requires locking for membership testing.

Linked PRs

• gh-132657: Add free-threading scaling benchmark for copy.copy and copy.deepcopy #132658
• gh-132657: Avoid locking in frozenset.__contains__ #132659

[eendebakpt]

I have no good approach yet to improve performance of the module level variables. This diff

diff --git a/Lib/copy.py b/Lib/copy.py
index c64fc076179..084b2873b65 100644
--- a/Lib/copy.py
+++ b/Lib/copy.py
@@ -67,7 +67,8 @@ def copy(x):

     cls = type(x)

-    if cls in _copy_atomic_types:
+    _local_atomic_types =  {int, float, bool, complex, bytes, str, type, range, property}
+    if cls in _local_atomic_types or cls in _atomic_types:
         return x
     if cls in _copy_builtin_containers:
         return cls.copy(x)

improves the scaling of copy.deepcopy a lot, but the solution is not very elegant and does not work for all test cases.

[colesbury]

The copy module uses module level variables in the copy.copy and copy.deepcopy methods

We've discussed making module level variables use deferred reference counting, which would address this problem, but haven't decided exactly how we want to implement it. (All global variables? Only some frequently accessed ones?)