NumPy 2.5: 25x Faster searchsorted and What Breaks

NumPy 2.5, released in June, rewrote the searchsorted function in C++ to make batched binary searches up to 25x faster, according to the Scientific Python blog post detailing the optimization. The speedup applies to arrays larger than CPU cache with hundreds of thousands of keys, while single-key calls are unchanged, and downstream libraries including SciPy, scikit-learn 1.9.1 (released September 10, 2026) and pandas benefit automatically with no code changes. The release also carries breaking changes, including np.linalg.eig and eigvals now always returning complex arrays even when all eigenvalues are real.

NumPy 2.5 shipped in June, and most coverage led with descending sort support or structural pattern matching. The real headline was buried in the performance notes: searchsorted — one of the most quietly critical functions in the scientific Python stack — got a C++ rewrite that makes batched binary searches up to 25x faster. SciPy, scikit-learn, and pandas all call it internally. You’re probably already getting the speedup without knowing it. Where searchsorted Lives in Your Stack If you’ve ever called pd.cut , pd.qcut , scipy.stats.percentileofscore , or any scikit-learn preprocessing that buckets continuous values, you’ve been running np.searchsorted under the hood. It’s the function that answers: given a sorted array, where does this value belong? The answer powers histogram binning, quantile lookups, time-series event matching, and vocabulary encoding in ML pipelines. python import numpy as np This is the pattern that benefits most from NumPy 2.5 bin edges = np.linspace 0, 1, 1000 data = np.random.rand 500 000 Passing an array of values — batched mode — gets the full speedup indices = np.searchsorted bin edges, data The function has always been fast for single lookups. The problem was at scale: when you pass a large array of query values, the old implementation ran each binary search sequentially. Each search jumped around memory in a pattern the CPU prefetcher could not predict, stacking cache misses on top of dependency chains. What Actually Changed The new C++ implementation runs all K searches in lockstep. Instead of completing one binary search before starting the next, it advances every active search by one step simultaneously — the same logical operation applied across all queries at once. The memory access pattern shifts from scattered random jumps to clustered reads near the array median, which is exactly what CPU caches and out-of-order execution pipelines are designed to handle. The memory overhead is O 1 : the algorithm tracks a single shared interval length rather than maintaining separate bounds per query. The C++ port writes results directly to the output array, with no temporary allocation. JAX uses a near-identical approach; PyTorch and TensorFlow prefer multithreaded partitioning, which is competitive but burns extra cores. According to the Scientific Python blog post detailing the optimization https://blog.scientific-python.org/numpy/searchsorted/ , this batching technique is the core reason for the dramatic gains. Benchmark numbers: up to 20–25x faster for hundreds of thousands of keys on arrays larger than CPU cache. Single-key calls are unchanged — no regression, no improvement. The speedup is real and the scope is accurate: batched binary search is what got faster, which is what production workloads actually use. The Free Upgrade: Downstream Libraries Benefit Automatically scikit-learn 1.9.1 released September 10, 2026 is compatible with NumPy 2.5. SciPy supports it. pandas works. That means pip install "numpy =2.5" in your data science environment and every quantile computation, every histogram, every feature binning step in those libraries gets improved performance with zero code changes on your end. The official NumPy 2.5.0 release notes https://numpy.org/devdocs/release/2.5.0-notes.html confirm the improvement applies to all built-in dtypes. Libraries depending on searchsorted — including SciPy and scikit-learn — automatically benefit without code modifications. Check the NumPy 2.5.0 GitHub release https://github.com/numpy/numpy/releases/tag/v2.5.0 for the full changelog. Breaking Changes to Audit Before You Upgrade NumPy 2.5 has real breaking changes. They are worth checking against your codebase before upgrading production dependencies. linalg.eig and eigvals now always return complex arrays — even when all eigenvalues are real. If your code checks w.dtype == np.float64 after calling np.linalg.eig , it will now fail. Switch to np.linalg.eigh or np.linalg.eigvalsh for symmetric or Hermitian matrices, which still return real results. Before NumPy 2.5: w might be float64 if eigenvalues happened to be real After NumPy 2.5: w is always complex128 — check your dtype assertions w, v = np.linalg.eig symmetric matrix Fix: use eigh for symmetric matrices w, v = np.linalg.eigh symmetric matrix returns real float64 numpy.where raises OverflowError on out-of-range integers — previously, passing a Python integer larger than the target dtype could hold resulted in silent truncation. Now it raises. This is correct behavior, but it surfaces bugs that were previously invisible. numpy.distutils is gone — if you maintain a package that used NumPy’s build infrastructure, the migration to scikit-build-core or meson is the path forward. numpy.row stack removed — use numpy.vstack instead. One-word find-and-replace, but it fails loudly if missed. Python 3.11 dropped — NumPy 2.5 supports Python 3.12 through 3.14 only. Upgrading Python is a prerequisite if you are still on 3.11. Other Performance Wins Worth Noting Beyond searchsorted, NumPy 2.5 brings modest but real improvements to common operations: sum , prod , any , and all on contiguous arrays run about 1.3x faster. Boolean any / all specifically reach up to 1.9x. For free-threaded Python builds 3.13+ , lock-free ufunc dispatch reduces contention in multi-threaded workloads. There is also proper descending sort support: np.sort arr, descending=True is now a thing. It stops the arr ::-1 workaround that appears in virtually every NumPy codebase. The Upgrade Path If you are running NumPy 2.x already, upgrading to 2.5 is low-risk. Run your test suite after upgrading — specifically check any code that calls linalg.eig , uses numpy.where with large integers, or depends on numpy.distutils . The searchsorted speedup requires no changes at all. If you are still on NumPy 1.x, this release — combined with the free-threading improvements in Python 3.14 — is a reasonable forcing function to finally migrate. The scikit-learn 1.9.1 installation docs https://scikit-learn.org/stable/install.html confirm compatibility with NumPy 2.5, so the ecosystem is ready. Most codebases need fewer fixes than expected.