gh-153198 Optimize set and frozenset membership lookup by rajat315315 · Pull Request #153199 · python/cpython

rajat315315 · 2026-07-06T14:17:28Z

Linked Issue

Fixes gh-153198

Proposed Changes

Modified Objects/setobject.c to:
- Add PyUnicode_CheckExact and unicode_eq() fast-path check in set_compare_frozenset.
- Mark set_do_lookup as static inline Py_ALWAYS_INLINE int so the compiler can specialize and inline the lookup loop for both comparison target functions.
Verified correctness by running test_set (all 644 tests passed successfully).

Benchmarks (1,000,000 lookup operations)

set_lookup (int keys): 20.1% faster (reduced from 42.2 ms to 33.7 ms)
set_lookup_str (string keys): 26.2% faster (reduced from 71.1 ms to 52.5 ms)
frozenset_lookup_str (string keys): 17.0% faster (reduced from 71.2 ms to 59.1 ms)

…t-path for identical Unicode keys

bedevere-app · 2026-07-06T14:17:33Z

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

python-cla-bot · 2026-07-06T14:17:33Z

All commit authors signed the Contributor License Agreement.

…s and adding a fast path

StanFromIreland

Please provide benchmarks, run on a PGO + LTO build.

StanFromIreland · 2026-07-06T15:04:40Z

 #define PERTURB_SHIFT 5

-static int
+static inline Py_ALWAYS_INLINE int


Is the compiler not already specialising this?

Below is a response from an AI agent:

Without explicitly using Py_ALWAYS_INLINE, the compiler is highly unlikely to inline or specialize this automatically for a few key reasons:

1. The Heuristics Threshold (Function Size)

Modern C compilers (GCC, Clang, MSVC) use conservative heuristics to decide what to inline. They estimate the number of instructions in a function, and if it exceeds a certain threshold, they won't inline it to avoid bloating the binary.

Because set_do_lookup contains:

An outer loop (while (1))

A nested loop (do { ... } while)

Complex index wrapping & perturbation logic (perturb >>= PERTURB_SHIFT)

Multiple status checks & returns

It is too large for compilers to automatically inline under default heuristics.

2. Compilers Cannot Devirtualize Pointers in Standalone Functions

If a function is not inlined, it must be compiled as a separate, general-purpose function. In that compiled code:

status = compare_entry(so, table, entry, key, hash);

must remain a generic function pointer call (an indirect branch).

The compiler cannot inline the comparison logic because it doesn't know which function is being called at runtime.

3. Even with LTO + PGO, Auto-Specialization is Not Guaranteed

While Link-Time Optimization (LTO) and Profile-Guided Optimization (PGO) allow the compiler to see across translation units and profile hot paths:

Function cloning / specialization heuristics (e.g., creating custom copies of set_do_lookup with resolved function pointers) are highly compiler-dependent and fragile.

By adding Py_ALWAYS_INLINE, we guarantee that all compilers on all platforms (GCC, Clang, MSVC) specialize and inline the lookup logic consistently, making the performance gain reliable.

Below is a response from an AI agent:

See our AI Policy, we expect PR authors and those filing issues to be able to explain their proposed changes in their own words.

Mentioning Py_ALWAYS_INLINE explicitly enforces the compiler to inline the function. But if we don't specify, it is not guaranteed even with LTO and PGO.
Making it inline has a lot of benefit as it will inline set_compare_frozenset() call as well as the compiler knows statically which function is being called rather than linking it at runtime via pointer.

Yes, it's not guaranteed, but modern compilers are pretty smart. Do new compilers already inline it?

StanFromIreland · 2026-07-06T15:04:48Z

While it might be less common, when string membership lookups are performed on a frozenset, the fast path is highly effective.
In our PGO+LTO benchmarks, it resulted in a 21.1% speedup (reducing lookup time from 68.5 ms to 54.0 ms).

Please post the benchmark script. This was considered before, and it was decided it's not worth it, you need to convince us we were wrong before. You also need to benchmark the two changes separately, and cases that aren't optimised to see what hit other paths take.

bedevere-app · 2026-07-06T15:05:21Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

StanFromIreland · 2026-07-07T08:39:59Z

Please do not use the Update Branch button unless necessary (e.g. fixing conflicts, jogging the CI, or very old PRs) as it uses valuable resources. For more information see the devguide.

rajat315315 · 2026-07-07T09:52:01Z

Oh Ok, I will take care from next time.

Here are the benchmark results run on a fresh PGO + LTO build (compiled with --enable-optimizations --with-lto=full using GCC 15.2.0 on Linux).

The benchmarks measure the time for 1,000,000 lookup operations (1,000 loops searching for 1,000 keys):

Benchmark (1,000,000 lookups)	Baseline (`main`)	Optimized (this PR)	Time Saved (%)	Speedup
`set_lookup_int`	61.859 ms ± 16.041 ms	50.429 ms ± 15.375 ms	18.5%	1.23x
`set_lookup_str`	75.043 ms ± 16.397 ms	53.779 ms ± 9.788 ms	28.3%	1.40x
`frozenset_lookup_str`	68.524 ms ± 9.395 ms	54.071 ms ± 5.390 ms	21.1%	1.27x

Specializing the comparison callback via Py_ALWAYS_INLINE on set_do_lookup yields a ~18.5% improvement for integer set lookups, while adding the PyUnicode_CheckExact() and unicode_eq() fast path check in set_compare_frozenset improves string lookup performance by 21% to 28%.

rajat315315 · 2026-07-07T09:52:05Z

I have made the requested changes; please review again.

bedevere-app · 2026-07-07T09:52:11Z

Thanks for making the requested changes!

@StanFromIreland: please review the changes made to this pull request.

StanFromIreland · 2026-07-07T09:56:06Z

I have made the requested changes; please review again.

I'm sorry but you have not, see my comments above.

sobolevn · 2026-07-07T11:05:50Z

    }
    Py_ssize_t ep_hash = ep->hash;
    if (ep_hash == hash) {
+        if (PyUnicode_CheckExact(startkey)


question: why did you decide to use str as the fast path items here? what is so special about it?

vstinner · 2026-07-07T13:22:56Z

Optimize set and frozenset membership lookup by inlining set_do_lookup and adding a PyUnicode_CheckExact fast path to set_compare_frozenset.

I don't see how such change can make set faster for any type. I expect that it makes set slower for types other than str.

It was decided recently to not specialize set for str: see #137828 discussion.

I suggest closing this PR.

perf: optimize set lookups by inlining set_do_lookup and adding a fas…

d25015b

…t-path for identical Unicode keys

rajat315315 requested a review from rhettinger as a code owner July 6, 2026 14:17

bedevere-app Bot added the awaiting review label Jul 6, 2026

rajat315315 changed the title ~~Optimize set and frozenset membership lookup~~ gh-153198 Optimize set and frozenset membership lookup Jul 6, 2026

bedevere-app Bot mentioned this pull request Jul 6, 2026

Optimize set and frozenset membership lookup (x in s) performance #153198

Closed

rajat315315 added 2 commits July 6, 2026 19:54

perf: optimize set and frozenset membership lookup by inlining lookup…

81f2fa7

…s and adding a fast path

Merge branch 'main' into set_membership_opt

110770e

StanFromIreland requested changes Jul 6, 2026

View reviewed changes

bedevere-app Bot added awaiting changes and removed awaiting review labels Jul 6, 2026

StanFromIreland added the pending The issue will be closed if no feedback is provided label Jul 6, 2026

Merge branch 'main' into set_membership_opt

70dbe4c

feat: introduce pyperf library for benchmark tracking and comparison

0d3823d

bedevere-app Bot added awaiting change review and removed awaiting changes labels Jul 7, 2026

bedevere-app Bot requested a review from StanFromIreland July 7, 2026 09:52

sobolevn reviewed Jul 7, 2026

View reviewed changes

sobolevn closed this Jul 7, 2026

Uh oh!

Uh oh!

Conversation

rajat315315 commented Jul 6, 2026

Linked Issue

Proposed Changes

Benchmarks (1,000,000 lookup operations)

Uh oh!

bedevere-app Bot commented Jul 6, 2026

Uh oh!

python-cla-bot Bot commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

StanFromIreland left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

1. The Heuristics Threshold (Function Size)

2. Compilers Cannot Devirtualize Pointers in Standalone Functions

3. Even with LTO + PGO, Auto-Specialization is Not Guaranteed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bedevere-app Bot commented Jul 6, 2026

Uh oh!

StanFromIreland commented Jul 7, 2026

Uh oh!

rajat315315 commented Jul 7, 2026

Uh oh!

rajat315315 commented Jul 7, 2026

Uh oh!

bedevere-app Bot commented Jul 7, 2026

Uh oh!

StanFromIreland commented Jul 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vstinner commented Jul 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

python-cla-bot Bot commented Jul 6, 2026 •

edited

Loading