I made a couple of changes and narrowed the optimisation down tofrozenset only. This is because the API could be used for sets that are either global variables or members of another wrapper. In such cases, the object can be accessed by multiple threads, even if it is uniquely referenced. I was thinking about the global variables, but thanks to@kumaraditya303 for pointing out the scenario involving wrappers as well.

The global variable or wrapper scenario is also relevant forfrozenset. However,API documentation specifies a special condition.

Also works withfrozenset instances (likePyTuple_SetItem() it can be used to fill in the values of brand new frozensets before they are exposed to other code)

If the condition "before they are exposed to other code" is sufficient to proceed with his optimisation, then we still have some wins (19% Intel, 27% ARM benchmarked after changes). Otherwise, I am going to close this PR and look for alternative.

@colesbury@sergey-miryanov, I haven’t included the double_PyObject_IsUniquelyReferenced() to handle the cases where hashing could introduce another reference and pass it to another thread forfrozenset. This is essentially exposing thefrozenset to other code, which is what the API documentation addresses.

However, it might be a good idea to move the hashing outside of thecritical_section in general, to minimize the time spent in the critical section. I can do it in a separate PR (or this) if that sounds reasonable to you.

Global variables are in fact not a concern, because those must be a separate reference (otherwise the set could be destroyed during PySet_Add, which can call arbitrary Python code that would delete the global). Other borrowed references are a concern, though (and not for the first time... Raah.)

Oh, it is good. Sorry for the noise.

Sorry, that was a mistake. I was trying to clean up branches.