[wasm] Compiled regexes in interpreter ~25-50x regression

[kg]

At some point recently, performance for BDN's compiled regex tests under the interpreter on wasm regressed by around 25-50x. See https://pvscmdupload.blob.core.windows.net/reports/allTestHistory/refs/heads/main_x64_ubuntu%2022.04_CompilationMode=wasm_RunKind=micro/System.Text.RegularExpressions.Tests.Perf_Regex_Common.MatchWord(Options%3a%20IgnoreCase%2c%20Compiled).html for one example.

I tested this in isolation and was able to reproduce bad performance, but I couldn't identify the cause, and the code involved is very complex so I couldn't make sense of what was going on. I didn't notice any misbehavior on the jiterpreter side of things for this scenario.

See dotnet/perf-autofiling-issues#29881 for diff range.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[stephentoub]

Maybe #98791 ? It would suggest that the interpreter doesn't currently play nicely with SearchValues<string>, e.g. using IndexOfAny to search a ReadOnlySpan<char> with private static readonly SearchValues<string> s_words = SearchValues.Create(["tempus", "magna", "semper"], StringComparison.OrdinalIgnoreCase);.

[kg]

Maybe #98791 ? It would suggest that the interpreter doesn't currently play nicely with SearchValues<string>, e.g. using IndexOfAny to search a ReadOnlySpan<char> with private static readonly SearchValues<string> s_words = SearchValues.Create(["tempus", "magna", "semper"], StringComparison.OrdinalIgnoreCase);.

It's possible, I wouldn't expect that to cause this big of a regression but iirc this regression set also included some SearchValues-related regressions.

[lewing]

you can still see the regression https://pvscmdupload.z22.web.core.windows.net/reports/allTestHistory/refs/heads/main_x64_ubuntu%2022.04_AOT=true_CompilationMode=wasm_RunKind=micro/System.Text.RegularExpressions.Tests.Perf_Regex_Common.MatchWord(Options:%20IgnoreCase,%20Compiled).html and the range is 9da5359...79dd9ba

[lewing]

cc @vitek-karas

[BrzVlad]

This performance issue is not related to mono interpreter, it is indeed caused by the Regex change linked above: commit.

@stephentoub The issue is related to support for RuntimeFeature.IsDynamicCodeCompiled/Supported. The commit above heavily degrades performance when the runtime doesn't use compiled dynamic code, impacting mono interpreter. Consider the following microbenchmark https://gist.github.com/BrzVlad/a2345bac59cf0ee472e27b7365a2379f. Running this testcase locally with CoreCLR, before your change it runs in 1.3s and after your change it runs in 0.75s. This looks great, however, if I forcefully disable the dynamic code support switches in CoreCLR in file, before your change it runs in 1.8 and after your change it heavily degrades to 71s, which is consistent to the regressions we are seeing on mono interpreter.

[stephentoub]

This performance issue is not related to mono interpreter, it is indeed caused by the Regex change linked above:

Per my comment in #99553 (comment), you don't see SearchValues<string> performing poorly in such cases?