-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decorate SequenceEqual with AggressiveOptimization #79645
Conversation
Tagging subscribers to this area: @dotnet/area-system-memory Issue DetailsI'm not sure this is good idea or not, I'm looking for feedback. We found out with @ilonatommy that Many of the other methods in the At this point I don't know what is customer impact.
|
I don't think we need any of the So far, for CoreCLR we only have two justifications for
|
We have #71261 opened on this. |
Are there existing benchmarks where the improvement can be seen, or a future regression caught? |
I don't know, we just explored one-off scenario locally. Thanks everybody for the explanation and the context. I'm closing it as I don't have strong evidence this has visible impact on wasm and it would probably have impact on CLR. |
Well, it raised a good question whether we should preserve existing [AO] for Mono if we decide to drop them for CoreCLR or not 🙂 |
I'm not sure this is good idea or not, I'm looking for feedback.
We found out with @ilonatommy that
string.Normalize
could be slow when running on Mono interp (in browser).The reason is that interp would tier up and optimize the
SequenceEqual
method only after 1000 calls.If we add
[MethodImpl(MethodImplOptions.AggressiveOptimization)]
the Mono interpreter would optimize it right away.Many of the other methods in the
SpanHelpers
are decorated same way. IsSequenceEqual
just missing the attribute ?At this point I don't know what is customer impact.