GH-141686: Break cycles created by JSONEncoder.iterencode

[brandtbucher]

As mentioned in the issue, clearing these cycles explicitly results in a ~10% slowdown for json.dump microbenchmarks when the GC is disabled, but a ~20% speedup when the GC is enabled (since we're now eagerly doing the work done less efficiently by the GC).

I've also removed a "hack" that tried to turn globals into locals (in practice these "locals" are actually cells). This may have been faster in the past, but what it really does now is turn cached LOAD_GLOBAL specializations into unoptimized LOAD_DEREF instructions. Removing these gives another ~10% or so speedup for me.

• Issue: json.JSONEncoder.iterencode creates reference cycles #141686

[serhiy-storchaka]

How does this affect performance for a large list of integers?

[brandtbucher]

Looks like doing things the "normal" way (int.__repr__) is about 0-10% faster on a little microbenchmark:

LOOPS = 1 << 24

def outer():
    _intstr = int.__repr__
    def old():
        for _ in range(LOOPS):
            _intstr(42)
    def new():
        for _ in range(LOOPS):
            int.__repr__(42)
    return old, new

def bench(func):
    start = time.perf_counter()
    func()
    end = time.perf_counter()
    print(end - start)

old, new = outer()
bench(old)
bench(new)

I think the combination of cell + bound method unwrapping is enough overhead to cancel out the gains from avoiding a (cached) global lookup and a (cached) attribute load. But it's pretty much in the noise anyways, so probably not worth keeping the old micro-optimization.

[efimov-mikhail]

This bench shows only 1-2% difference on my machine.

[serhiy-storchaka]

Thank you. On my machine, this bench shows 2-3% difference on 3.14 and main and 20-25% difference on 3.12 and 3.13. So this micro-optimization was justified in the past, but perhaps not so much now. It cannot be backported if you are planning to backport this PR.

[brandtbucher]

No plans to backport.

[serhiy-storchaka]

LGTM. 👍

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 Debian root 3.x (tier-1) has failed when building commit 4cfa695.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/345/builds/12711) and take a look at the build logs.
4. Check if the failure is related to this commit (4cfa695) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/345/builds/12711

Failed tests:

• test.test_os.test_os

Failed subtests:

• test_timerfd_ns_poll - test.test_os.test_os.TimerfdTests.test_timerfd_ns_poll

Summary of the results of the build (if available):

==

Click to see traceback logs

Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_os/test_os.py", line 4123, in test_timerfd_ns_poll
    self.check_timerfd_poll(True)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_os/test_os.py", line 4108, in check_timerfd_poll
    self.assertEqual(self.read_count_signaled(fd), 1)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 8 != 1


Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_os/test_os.py", line 4123, in test_timerfd_ns_poll
    self.check_timerfd_poll(True)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_os/test_os.py", line 4108, in check_timerfd_poll
    self.assertEqual(self.read_count_signaled(fd), 1)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 3 != 1