Implement StringPairs for efficient pairs(::AbstractString)

[jakobnissen]

The default pairs will iterate keys and values separately. For strings, this represents double work, since both these iterations will need to determine valid string indices.
The introduced StringPairs type will, whenever possible, only compute valid indices once.
Currently, this is only optimised for String and SubString{String}, and not for AbstractString, nor is it optimised when reversed.

Simple benchmark:

using BenchmarkTools
a = lpad("March", 20)
@btime lstrip($a)

• Master: 71.6 ns
• This PR: 23.9 ns

Closes #51624

[StefanKarpinski]

This looks good to me and is a nice optimization.

[oscardssmith]

Is this a better solution than #51671?

[jakobnissen]

See my comment here: #51631 (comment)
They both improve timings, and both PRs together are faster than either one.

[jakobnissen]

Is there anything else that needs to be done here? FWIW, I profiled lstrip, and didn't see the SubString constructor take any significant time (as suggested by this comment) - most time was spend in string iteration.

[DilumAluthge]

@vtjnash Could you give this another review?

[vtjnash]

It sounds like someone still needs to investigate and fix the actual performance issue (#51631 (comment))

[jakobnissen]

Okay, so I did two benchmarks. One simply measures the performance of pairs(::String), which is what this issue is really about. This is the benchmark

function time_pairs(s::String)
    n = 0
    for (i, c) in pairs(s)
        n = xor(n, reinterpret(UInt32, c) * i)
    end
    n
end

for source in ["en", "dk", "cn"]
    src = read(source, String)
    short = first(src, 20)
    println(source, " long:  ", @belapsed time_pairs($src))
    println(source, " short: ", @belapsed time_pairs($short))
end

With three difference sources: English (all ASCII), Danish (mostly ASCII) and Chinese (little ASCII). Results

            master    #51671    #51671 & this
en, short  53.8 ns    37.3 ns   19.9 ns    
en, long   21.7 us    17.4 us   11.8 us
da, short  57.3 ns    26.1 ns   19.6 ns
da, long   28.9 us    13.1 us    9.3 us
cn, short  116  ns    112  ns   52.9  us
cn, long   16.9 us    18.3 us    9.7 us

And here, for a simple lstrip benchmark:

bar(s) = sum(ncodeunits(lstrip(c -> reinterpret(UInt32, c) >>> 24 > 10, s)) for i in 1:10000000)

This takes ~950 ms on #51671, and ~640 ms on #51671 + this PR
This uses - on #51671 + this approximately:

• 91% of time in lstrip
• Of that, approximately 18% in SubString
• 44% in iterate
• I don't know what the rest is. Most of it shows up as "overhead" of lstrip in benchmarking. The benchmark does not allocate.

So, this PR is a clear win.

[jakobnissen]

Bump. What needs to be done to get this through?

[jakobnissen]

I've added "needs nanosoldier" because the noinline in string iteration may have unintended side effects. For example, it makes iteration of Cyrillic 2x slower and Chinese 1.6x slower. On the other hand, it allows iterate to inline itself so it will be faster for ASCII in many contexts. Just like the recent changes to nextind. So let's check its impact.
If the impact is unacceptable then I'll close this PR because then I don't know how to add the algorithmic improvement in this PR without causing regressions

[vtjnash]

@nanosoldier runbenchmarks("shootout" && "misc" && "io" && "string" && "strings", vs=":master")

[vtjnash]

It may still be worthwhile for someone to figure out why this isn't handled in the compiler already (past analysis suggested it was a problem with the way it used the SubString constructor #51631 (comment)), but might as well take the win now

[nanosoldier]

Your benchmark job has completed, but no benchmarks were actually executed. Perhaps your tag predicate contains misspelled tags? cc @

[vtjnash]

@nanosoldier runbenchmarks("shootout" || "misc" || "io" || "string" || "strings", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[jakobnissen]

@DilumAluthge thanks for keeping this up to date. This is good to go now.

[jakobnissen]

Bump