`str.find` equal length fast path

[dg-pb]

Feature or enhancement

Proposal:

memcmp is being used in /Objects/stringlib/eq.h.
It can also be used as a fast path when 2 strings are of the same size for str.find and str.count.

PYMAIN="/Users/Edu/local/code/cpython/main/python.exe"
PYWT1="/Users/Edu/local/code/cpython/wt1/python.exe"
$PYMAIN -m timeit -s 'a = "abc" * 100_000; b = str(a)' 'a.find(b)'  # 273 µs
$PYWT1 -m timeit -s 'a = "abc" * 100_000; b = str(a)' 'a.find(b)'   #  11 µs

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-155555: str.find equal length fast path #155556

[picnixz]

How likely do we have a case where find() has the same size as the inupt? I question this "fast path"

[dg-pb]

Not very likely.
Some odd ones on programmatic usage.

However, for strings of equal length, why a == b should be faster than a.find(b)? It is a certain inconsistency, which can be easily eliminated with minimal addition.

[picnixz]

• Why: because it's odd to use find() in this case
• This adds a maintenance cost, even slightly small.
• This creates yet another divergence with other branches.

I'm not really convinced by adding a fast path just for that. I can see why we have a fast path for m == 1 (though not really for m == 0) but I don't see why we should microoptimize everz part of the library for niche cases.

[dg-pb]

m == 1 is very useful. Agreed. And there are whole separate functions for that (there is even separate brach for infinite count).

While this is a small benefit - small cost (3 lines of peace-of-mind) change that covers all permutations (find/count/fwd/rev).

Without this, sooner or later someone will do:

for ...:
    idx = (s1.find(s2) if len(s1) != len(s2) else -1 * (s1 != s2))

• Why: because it's odd to use find() in this case

Agreed. It is odd to do it explicitly being aware that they are of equal length.

• This adds a maintenance cost, even slightly small.

Which IMO is reasonable as the benefit is also "slightly small".

• This creates yet another divergence with other branches.

Same as above - small cost for small benefit. Branch is self contained and I can not see any issues - it being just one more in a space packed with quite a few of them. I have been looking at string search for a while now (since #120025) and this is the only one that I found which could be a good addition since.

[picnixz]

As usual, we prefer not adding code if there is no real gain for real use cases. It's not the spirit of the project. I don't think you need to force into adding an optimization just for the sake of having an optimization.

for ...:
    idx = (s1.find(s2) if len(s1) != len(s2) else -1 * (s1 != s2))

Why would someone do this? it's an implementaion detail. Unless they look at the interpreter they won't know about it. I don't think it's fair to assume this. So, this example is not convincing to me.

---

I'm going to ask others but I am not really in favor of adding more code just for "fast" paths that are uncommon. Fast paths are meant to be used for common cases. Otherwise, we can have lots of fast paths a bit everywhere. That's a general policy IMO.

cc @methane @rhettinger @serhiy-storchaka @vstinner

[serhiy-storchaka]

Concur with @picnixz.

[methane]

-0. I still haven't come up with a typical use case where this optimization would be useful.