Open
Description
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
copymodule uses module level variables in thecopy.copyandcopy.deepcopymethods. - The
_copy_atomic_types(and some similar data structures) is asetwhich requires locking for membership testing.
Linked PRs
Metadata
Metadata
Assignees
Labels
Performance or resource usagePerformance or resource usagePython modules in the Lib dirPython modules in the Lib dirAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error