Added Benchmark for SpanHelpers.Contains {byte, char}

[gfoidl]

Cf. dotnet/runtime#67492 (comment)

I created a new file for this benchmark, as the current benchmarks for Span didn't fit here really well -- though I'm not sure if my benchmarks here are over-engineered.

For e.g. SpanHelpers.IndexOf there is a benchmark (

performance/src/benchmarks/micro/libraries/System.Memory/Span.cs

Line 69 in a37c8e3

public int IndexOfValue() => new System.Span<T>(_emptyWithSingleValue).IndexOf(_notDefaultValue);

), but this one has (maybe) same flaws:

• it tests only one length (constant 512)
• it doesn't take into account the different pathes that are gone due to vectorization
• it doesn't cover the edge-cases from the vectorized pathes
• BUT: they run fast

At least for the PR dotnet/runtime#67492 I covered these cases, but the execution time for the benchmarks rises.

So I'm not sure what's the right balance here. Especially if we take ARM also into account, then there maybe different cut-offs for the edge-cases making the combinations grow up.

On one hand I think the benchmark should cover edge-cases -- here the perf-critical ones -- too, but on the other hand they should give an good enough estimate on how well the code is performing.

PS: If this should be discussed in an issue rather than this PR here, please create an issue, edit this PR, whatever is best.

[gfoidl]

At the moment these values are based on Vector<T>.Count on x64 with AVX2 enabled.
So for e.g. ARM where Vector<byte>.Count is 16 (instead of 32 as on x64) the values should be halfed.

Via ParamsSource this could be taken into account. Shall I update to this?
(Didn't do now, because of the discussion in the PR's description -- i.e. I'd like to an outcome from this first).

[danmoseley]

@adamsitnik might suggest.

[danmoseley]

@adamsitnik could you advise, so we can get this merged?