Repository navigation
Speed up integer searching in memoryview and array.array #159716
Description
Feature or enhancement
Currently for memoryview and array.array operations like .index() and .count() convert elements from native byte format to a PyObject then call PyObject_RichCompareBool to compare them. This is significantly slower than the equivalent bytes as reported on discord.
data = memoryview(bytearray(64 * 1024))
data[-1] = 10
data.index(10, 100) # ~860x slower than bytes(data).index(10, 100)For one dimensional memoryview and array.array when the items are native integer formats (struct formats bBhHiIlLqQnN) we can do the comparison as event bytes using optimized methods for 1-, 2-, 4- and 8-byte comparison.
Note this does not apply for objects like float where exact-byte comparison does not work (0.0 == -0.0).
Detect the cases we can make faster and generalize existing helpers for "packing" into native bytes and comparing buffer protocol objects with 1-, 2-, 4-, and 8-byte types which are exact-byte comparable.
Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
- https://discuss.python.org/t/memoryview-index-860x-slower-than-bytes-index/104973
- memoryview is a Sequence but does not implement the full Sequence API #125420: addition of memoryview.index() and count()
Activity
picnixz commented on Oct 19, 2026
FTR: this was a deliberate choice of being slow because I still didn't have a real use case for that one. How likely do you need to look for integers in memorviews in general? or counting them?
cmaloney commented on Oct 19, 2026
My goal here is to make memoryview() usable as a default in more cases to avoid issues with slicing bytes() and bytearray() which when sliced must allocate and copy data. Having the same methods available and them be equivalently fast means when people experiment after learning "memoryview might be faster in a parser" don't hit as many speedbumps. memoryview serves as a "fast" slice which doesn't own the data it points at. It just keeps a reference to the object and some offset + length information.
I plan in this to have the bytes, array.array, and memoryview share the same implementation for these as much as possible to minimize maintenance cost. bytes is a special case of what array.array and memoryview need. Could only optimize the bytes case but doing 1-byte, 2-byte, 4-byte, and 8-byte integer-like objects isn't a lot of added code and are fairly common in codebases.
pythongh-159716: Speed up searching integer arrays and memoryviews
pythongh-159716: Speed up searching integer arrays and memoryviews