Faster searchsorted methods for range and array inputs

[IanButterworth]

For searching through an AbstractRange, the fastest one can use searchsortedfirst to evaluate multiple values currently is:

function foo(r, x)
   i = similar(x, keytype(r))
   @inbounds for ci in CartesianIndices(x)
       i[ci] = searchsortedfirst(r,x[ci])
   end
   return i
end
r = 0x00:0x02:0xff;
x = rand(UInt8, 1000, 1000);
@btime foo($r, $x)

  6.159 ms (2 allocations: 7.63 MiB)
1000×1000 Matrix{Int64}: ...

This PR provides the following, which only checks for one-based indexing and the length of r once, given they are expensive. It can also be preallocated:

@btime searchsortedfirst($r, $x)

  3.193 ms (2 allocations: 7.63 MiB)
1000×1000 Matrix{Int64}: ...

i = similar(x, keytype(r));
@btime searchsortedfirst!($i, $r, $x) 

  2.830 ms (0 allocations: 0 bytes)
1000×1000 Matrix{Int64}: ...

I didn't extend the methods for searching through AbstractVectors, as I didn't see a performance limitation with using those looped through values

[mcabbott]

Is it necessary to require one-based indexing at all? Perhaps + one(keytype(a)) can just be + firstindex(a), or does this go wrong somewhere?

[IanButterworth]

Maybe! Would zero become firstindex(a) - 1?

I didn't feel confident enough to try to handle non one based indexed ranges. I assume that it would require adding test cases for stuff out in the ecosystem that I'm unaware of

[mcabbott]

The only example I know if is the axes of OffsetArrays, which behave like this:

julia> OffsetArray('a':'z', -10)
'a':1:'z' with indices -9:16

julia> axes(ans, 1)
OffsetArrays.IdOffsetRange(-9:16)

julia> axes(ans, 1)
OffsetArrays.IdOffsetRange(-9:16)

The general idea here is similar to JuliaMath/IntervalSets.jl#63, in which it wasn't so hard to allow offsets. But that can depend on the package for tests. I think there is a (simplified?) implementation of this loaded for tests, e.g. https://github.com/JuliaLang/julia/blob/master/test/offsetarray.jl

[KristofferC]

Is the addition of the new API (the bang versions of searchsortedxxx) necessarily coupled with the rest of this PR?

[IanButterworth]

Not necessary, but logical I think. I think it would be odd to add the array-based methods without allowing preallocation.

Do you think the PR needs to be split?

[vtjnash]

While looking into this, I sought to understand the code, and realized there was a broken case resulting as the code had been slowly diverging over the years. I think this can be replaced by #40364 and #40358, and achieves the same performance objective without needing these new methods

[IanButterworth]

Nice. Thanks!

[IanButterworth]

Closing given superseded by #40364 and #40358