-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Avoid boxing ArgumentNullException.ThrowIfNull arguments in Tier-0 #104512
Comments
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
I assume these are not library-level changes, but JIT/compiler special casing of some sort? Would it be possible to "fix" this problem purely via library modifications instead? The reason I ask is that I'd like to be able to expand on existing validations with .NET9/C#13 extension types in the future and have them be as efficient as the native method if possible. If the team decides for a special case for the method, then that makes it impossible for library authors and consumers to leverage the same benefits with their own extensions later (correct me if I'm wrong here). |
This was discussed in #104504 (comment) . The library-only fix would be to add generic overload. However, the startup runtime cost of such generic overload for |
@tarekgh , @jkotas mentions this on that message:
Isn't this concern now taken care of by the new attribute that is being introduced to control overload resolution order? Can't we now use that attribute (or extend its capabilities) to support this scenario of only picking the generic overloads when trying to match from a generic type? |
|
What about making the priority be conditional then @stephentoub ? Would that be feasible? I understand the current implementation doesn't allow it, but what if it was expanded to? Surely the point where the decision is made has the required information, it would just be a matter of exposing that to the "priority setter" to allow for customization based on whether the type is generic or not? Or if the team doesn't want to open the API that much, just maybe have an extra boolean property in the attribute to control the applicability of the priority to generic types etc. Wouldn't that be preferable to JIT-level optimizations in this case since that would provide the benefit to all library use cases? |
You're talking about revising/augmenting a language feature (and one which is part of one of the most complicated parts of the language, that of overload resolution). That would need to be proposed and discussed over in dotnet/csharplang. |
ArgumentNullException.ThrowIfNull can incur boxing when applied to argument of generic type. Tier-1 JIT optimizations are able to optimize this boxing in steady state, but Tier-0 JIT optimization are not. It can result into excessive allocations during startup.
From @AndyAyersMS: We'd have to mark the method as intrinsic and add new logic to
impBoxPatternMatch
.More context and discussion of alternatives:
#104504
#82227
#100406
The text was updated successfully, but these errors were encountered: