[mono] Raise inlining length limit in the interpreter from 20 to 30 #83490
Conversation
… enough to allow List<T>.get_Item to be inlined, among other things
|
Tagging subscribers to this area: @BrzVlad, @kotlarmilos Issue DetailsIn the past raising the inlining length limit provided some big easy wins on wasm, and it also allows the jiterpreter to work better. Some critical stuff like List.get_Item is in this 'over 20 bytes but under 30 bytes' range. For example, V8.Crypto from the dotnet/performance suite is significantly bottlenecked on ListX.get_Item, which just calls List.get_Item. Previously when I tried this (as part of another PR) it caused one specific obscure test to fail on CI that didn't fail locally, so we'll see if it fails again and I can figure it out...
|
|
Looks like it still breaks. It used to cause a specific assertion (I'll have to see if I can find it) but now it causes random segfaults. :( |
Looking closer, one segfault is a known issue, and the other is in a lane that shouldn't engage the interpreter, so they might be random CI flakes. Will re-run. |
ghost
locked as resolved and limited conversation to collaborators
In the past raising the inlining length limit provided some big easy wins on wasm, and it also allows the jiterpreter to work better. Some critical stuff is in this 'over 20 bytes but under 30 bytes' range. For example, V8.Crypto from the dotnet/performance suite is significantly bottlenecked on ListX.get_Item, which just calls List.get_Item.
Previously when I tried this (as part of another PR) it caused one specific obscure test to fail on CI that didn't fail locally, so we'll see if it fails again and I can figure it out...