After tuple (commit 69ac6e5) and list (commit 88ec919) and others types (see bpo-40521), it's now the turn of dict to get its free lists moved to PyInterpreterState! FYI when I measured the tuple PR overhead, it was around 1 ns (and create a tuple of 1 item is around 20 ns): see PR #20247.

cc @methane @pablogsal

With this PR, all free lists cleared by gc.collect() are per-interpreter.

Before anyone asks, here is a microbenchmark on PyDict_New() to measure the overhead of this PR:

Mean +- std dev: [ref] 10.9 ns +- 0.9 ns -> [patch] 12.8 ns +- 1.0 ns: 1.18x slower (+18%)

The PR adds +1.9 ns per PyDict_New() call.

I used bench_dict.patch which is attached to https://bugs.python.org/issue40521.

UPDATE: please notice that the std dev is around 1 ns which is close to the overhead. These microbenchmark are so small that it is really hard to get a precise measure of timings.

@vstinner Would you benchmark without freelist too?
If benefit of the freelist becomes too small, removing it is better than making it per-interpreter.

@vstinner Would you benchmark without freelist too?

Here you have:

vstinner@apu$ python3 -m pyperf compare_to ref.json patch.json no_freelist.json 
Mean +- std dev: [ref] 10.9 ns +- 0.9 ns -> [patch] 12.8 ns +- 1.0 ns: 1.18x slower (+18%)
Mean +- std dev: [ref] 10.9 ns +- 0.9 ns -> [no_freelist] 18.0 ns +- 1.0 ns: 1.65x slower (+65%)

If benefit of the freelist becomes too small, removing it is better than making it per-interpreter.

Disabling the free list adds +7.1 ns per PyDict_New() call: 1.65x slower. It doesn't sound reasonable to remove free_list in dictobject.c.

TODO: implement commit bcb1983 for dict free lists. See https://bugs.python.org/issue40887 for the context.

@methane: So, what do you think?

I rebased my PR on top of the master branch.

TODO: implement commit bcb1983 for dict free lists. See https://bugs.python.org/issue40887 for the context.

Done. In debug mode, trying to use dict free lists after they are finalized now fails with an assertion error.

I'm OK to merge this.

Thanks @methane for the review! I'm still interested to attempt to reduce the overhead of this change. See my PR #20767 for example. But so I failed to find a method which has a significant impact on performance.

Again, measuring performance of a function taking around 10 ns is really hard. The machine code changes depending on LTO and/or PGO build modes, compiler flags, etc. And sometimes it's faster, sometimes it's slower...