[aivarsk]

One less hash calculation and lookup per circular reference check.

• Issue: json.dumps: single circle markers hash lookup #161661

[picnixz]

This adds a Py_DECREF path which may, on free-threading, introduce refcounting contention. Can you check the impact as well please?

[aivarsk]

The synthetic test with a lot of containers there is improvement for free-threading as well but a bit smaller.
GIL: base → branch: 33.73 → 32.05 ms (-5.0%)
FT: base → branch : 40.59 → 39.08 ms (-3.7%)

[picnixz]

What about pyperformance's JSON benchmark? And how is the synthetic benchmark done? (PGO+LTO? release build? pyperf or time? if it's timeit, use pyperf instead)

[aivarsk]

The built was just a plain -O3, no PGO+LTO. The existing pyperformance cases did show 0.x improvement but that's insignificant. Could be noise in eiter direction, as this is my laptop.
My synthetic testcase did use pyperf, just with a lot of nested containers to pressure the circular checks
jsondumps.py

[picnixz]

FTR, please don't add attachments. Users usually don't want to download code so prefer using inline blocks (in a <details> section).

[picnixz]

I think the change could be done but at the same time, I'd prefer not touching code that has been settled for a while especially considering the lack of significant performance in either direction.

So I'll defer the final decision to @serhiy-storchaka

[nineteendo]

How does this compare to using a set?

[aivarsk]

@nineteendo haven't tried it because markers is a dict and here it's a minimal change without API changes I came up with during #137103. If API change is on the table I think limiting recursion depth like other libraries do is the best way.

[nineteendo]

I think you can also check the size before and after adding the element.