Add a self-comparison fast path for some built-ins types

[dima179-fuse]

Feature or enhancement

Proposal:

a = [0] * 1000000
b = [0] * 1000000
timeit.timeit("a == b", globals=globals(), number=1000)
Out: 0.5669927500130143
timeit.timeit("a == a", globals=globals(), number=1000) # should be faster?
Out: 0.5312646660022438

for strings:

s1 = "a" * 1000000 + "b"
s2 = "a" * 1000000 + "c"
timeit.timeit("s1 == s2", globals=globals(), number=1000)
Out: 0.017710374988382682
timeit.timeit("s1 == s1", globals=globals(), number=1000)
Out: 1.5166995581239462e-05

Why doesn't Cpython, in the example above, return True from the == simply based on the object being compared to itself, whereas this optimisation is there for strings?

I made my own branch with such optimization: dima179-fuse#1
It appears to make some benchmarks faster, and tests pass.

result.txt

Also attached are pyperformance results for both my branches and main:
2025-11-21_21-36-main-92972aea0f0e.json.gz

self-list-comparison-optimisation-e4ebdcbb8b51.json.gz

standard-containers-comparison-optimisation-54518a64f037.json.gz

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-141858: Speed up Objects/tupleobject.c richcompare with early identity and length checks #142027

[dima179-fuse]

The same optimisation could also be applied to dicts, sets and tuples: dima179-fuse#2, I believe

[gvanrossum]

The answer to your question is that it is possible for objectors compare equal to themselves (e.g. NaN).

Also how often do you encounter this?

[tim-one]

"The rules" are more nuanced than Guido acknowledges here 😉.

>>> import math
>>> s = [math.nan]
>>> s == s
True
>>> s == [math.nan]
True

>>> d = {math.nan : 12}
>>> d[math.nan] = 42
>>> d
{nan: 42}

So object identity is used for equality in some contexts. But not in others:

>>> math.nan == math.nan
False
>>> math.nan is math.nan
True

My objection is more pragmatic: "fast paths" not only speed the case you're looking at, they also slow down all other cases, by the time it takes to burn cycles to determine that "nope, this case isn't special". So adding them is generally a "pessimization" unless the special cases are very common. Maybe not even measurably so in isolation, but even tiny pessimizations add up over time,.

I'm having a hard time recalling any code I've used where comparing a list to itself would ever happen.

[dima179-fuse]

My objection is more pragmatic: "fast paths" not only speed the case you're looking at, they also slow down all other cases, by the time it takes to burn cycles to determine that "nope, this case isn't special". So adding them is generally a "pessimization" unless the special cases are very common. Maybe not even measurably so in isolation, but even tiny pessimizations add up over time.

Also how often do you encounter this?

I appreciate that it slows down slightly each normal comparison (although comparing two pointers seems very marginal if you are about to execute comparison of python objects), and comparing a container to itself doesn't seem like something that is done often, however, the results of the benchmark runs I did (unless I made something wrong there) seem to prove otherwise.

benchmark_comparison.txt

While every instance that slowed down is tagged as "Not significant", there are some that appear to show a significant improvement:

python_startup_no_site
Mean +- std dev: 9.19 ms +- 0.24 ms -> 7.75 ms +- 0.13 ms: 1.19x faster
Significant (t=75.24)

async_tree_eager_io
Mean +- std dev: 226 ms +- 10 ms -> 213 ms +- 9 ms: 1.06x faster
Significant (t=7.55)

asyncio_tcp
Mean +- std dev: 238 ms +- 50 ms -> 211 ms +- 39 ms: 1.13x faster
Significant (t=3.26)

[dima179-fuse]

I did some more digging, namely, added logging each time a container is being compared to itself and recorded the following:

% pip install requests
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a list of size 2 is being compared to itself
Requirement already satisfied: requests in ./venv/lib/python3.15/site-packages (2.32.5)
Requirement already satisfied: charset_normalizer<4,>=2 in ./venv/lib/python3.15/site-packages (from requests) (3.4.4)
Requirement already satisfied: idna<4,>=2.5 in ./venv/lib/python3.15/site-packages (from requests) (3.11)
Requirement already satisfied: urllib3<3,>=1.21.1 in ./venv/lib/python3.15/site-packages (from requests) (2.5.0)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.15/site-packages (from requests) (2025.11.12)

>>> import requests
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
a tuple of size 2 is being compared to itself
>>> requests.get("2ip.ru")
a dict of size 2 is being compared to itself
a dict of size 2 is being compared to itself
a dict of size 2 is being compared to itself
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    requests.get("2ip.ru")
    ~~~~~~~~~~~~^^^^^^^^^^
  File "/Users/dima179/cpython/venv/lib/python3.15/site-packages/requests/api.py", line 73, in get
    return request("get", url, params=params, **kwargs)
  File "/Users/dima179/cpython/venv/lib/python3.15/site-packages/requests/api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/dima179/cpython/venv/lib/python3.15/site-packages/requests/sessions.py", line 575, in request
    prep = self.prepare_request(req)
  File "/Users/dima179/cpython/venv/lib/python3.15/site-packages/requests/sessions.py", line 484, in prepare_request
    p.prepare(
    ~~~~~~~~~^
        method=request.method.upper(),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<10 lines>...
        hooks=merge_hooks(request.hooks, self.hooks),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/Users/dima179/cpython/venv/lib/python3.15/site-packages/requests/models.py", line 367, in prepare
    self.prepare_url(url, params)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/Users/dima179/cpython/venv/lib/python3.15/site-packages/requests/models.py", line 438, in prepare_url
    raise MissingSchema(
    ...<2 lines>...
    )
requests.exceptions.MissingSchema: Invalid URL '2ip.ru': No scheme supplied. Perhaps you meant https://2ip.ru?
>>> 

I will try to find more examples like this later today.

[chris-eibl]

Good candidates for more examples might be those pyperformance benchmarks you've shared that show the highest speedups?

[tim-one]

Can't guess from here, alas, but benchmarking for speed is actually very difficult on modern boxes - HW has gotten so very complex, and runtimes routinely vary by up to 10% from one run to the next unless you make extraordinary efforts to keep your box utterly quiet (apart from the thing you're timing), and nail down obscure confounding effects like the OS moving a process from one core to another while it's a running ("process affinity"), or even a CPU deciding to reduce clock frequency to reduce thermal stress.

So I don't even bother to look at a thing unless it's at least 10% slower (or faster) across each of three runs. The aggregate speedup/slowdown geometric mean of a suite of benchmarks is a better measure - but then that also tends to hide "genuine" speedups from special-casing that benefits some programs but doesn't hurt others.

No easy answers, alas.

[dima179-fuse]

Ran the tests for sqlalchemy and requests. Also ran pyperformance --fast with the logging of these comparisons:

ppf_stderr.txt
ppf_stdout.txt
requests.txt
sqla.txt

[picnixz]

Can you give the benchmarks in the issue directly, instead of giving files? It'd be easier for everyone. TiA.

[dima179-fuse]

Can you give the benchmarks in the issue directly, instead of giving files? It'd be easier for everyone. TiA.

Do you want me to use pyperformance upload the results somewhere, or how does it work?

[sergey-miryanov]

You can format comparison result as a table (pyperformance and pyperf have such commands) and put here with triplebacktics.