gh-91603: Speed up UnionType instantiation (alt)

[serhiy-storchaka]

Co-authored-by: Yurii Karabas [email protected]

It is a rewriting of #91865.

Closes #91603.

[serhiy-storchaka]

The new code is even shorter than the old one!

 1 file changed, 77 insertions(+), 87 deletions(-)

[uriyyo]

@serhiy-storchaka Just compare performance with my version. It's almost identical:

Benchmark	yurii	serhiy
int | float	68.8 ns	73.2 ns: 1.06x slower
int | (list | float)	136 ns	139 ns: 1.02x slower
float | set | int | int | float | list	307 ns	288 ns: 1.06x faster
bool | int | float | complex | str | bytes | bytearray | list | set | frozenset | dict | range | property | classmethod | staticmethod | Exception	1.41 us	1.61 us: 1.14x slower
Geometric mean	(ref)	1.02x slower

Benchmark hidden because not significant (3): (int | float) | list, (int | float) | (list | set), (float | set) | int | int | (float | list)

[uriyyo]

LGTM

[serhiy-storchaka]

I am not surprised because it is the same algorithm.

"type | type" may be slightly slower because the code is more general, but it is a honest price for simpler code. On other hand, my code avoid creation a new tuple and a new UnionType object if possible, so it is expected that cases like float | set | int | int | float | list may be slightly faster.

I was skeptical about advisability of such optimization at all, but if it also reduces the size of the code I have no doubts.

[JelleZijlstra]

Looks mostly good, but I have a question about refcounts.

[JelleZijlstra]

Don't we need to INCREF here?

[serhiy-storchaka]

No, it is a borrowed reference.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @JelleZijlstra for commit a4badbc 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.