-
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
[mono] Miscellaneous startup optimizations #101263
Conversation
) { | ||
if (m_class_is_exception_class (klass->parent)) | ||
klass->is_exception_class = 1; | ||
else if (!strcmp (klass->name, "Exception") && !strcmp(klass->name_space, "System")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a mono_defaults.exception_class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think that's not applicable here since it wouldn't have a value while we're initializing System.Exception, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"it is pretty safe to assume that they won't be called in hot paths"
I'm not sure that this is always true. In particular, I think for exception propagation on async methods there's a bunch of work (withInnerException
) that could be considered "hot".
OK, I'll restrict it to not inlining ctors, that should still help a lot with wrappers |
Can confirm that not inlining exception ctors is sufficient to stop the inlining explosion in wrappers. Cuts 60 methods (inlined) out of this startup trace. |
* Optimize out an unnecessary memset under g_slist_prepend * Don't inline constructors of Exception or its descendants into interpreter method bodies
* Optimize out an unnecessary memset under g_slist_prepend * Don't inline constructors of Exception or its descendants into interpreter method bodies
generate_code
invocations during startup from 862 to 802, a reduction of 60. It's possible this might be too aggressive.