I'd like to see a benchmark and its results. I expect that maintainers would be interested in that too.
#4387 is an example for a similar benchmark added to this repo.

I also recall my past observation that wmemchr is slow and not vectorized. See DevCom-1614562. If this still confirms, I suggest reusing the std::find vectorization implementation instead of wmemchr

@mcfi's internal OS-PR-11111227 "[Perf] Optimize wmemcmp/wmemchr in UCRT" has enhanced <wchar.h> with vectorized implementations for x64 and ARM64, which have been benchmarked there as up to 10x faster. Although it'll be some unspecified amount of time before we're able to pick up updated UCRT headers, I'm fine with calling the UCRT now - this is our historical practice and only in highly unusual cases (e.g. #4654) do we avoid the UCRT.

Since this is deferring to our usual dependency, I also don't think it's absolutely necessary to add benchmarks to the STL repo.

Also, we're already calling wmemcmp and wmemchr in C++14 mode (expand context below the diffs), so I have absolutely no concerns here.

Updated title - the header is <__msvc_string_view.hpp> but this applies to char_traits and thus std::wstring etc.

Should anything be done with this then?

Good catch @AlexGuteniev! I think we can handle those in a followup PR (except that changing the ABI-retained function is pointless). I've recorded a note.

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

except that changing the ABI-retained function is pointless

Don't think so. The function used to be the optimization that we reverted to make ASAN happy.
Using wmemchr brings the optimization back, mitigating the ASAN happiness impact. (Not fully eliminating though, as there are 32 and 64 bit versions too)

Thanks for this (future) performance improvement! 🚀 📆 ⏳