Skip to content
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

Merged
merged 4 commits into from
Apr 23, 2024
Merged

Conversation

kg
Copy link
Contributor

@kg kg commented Apr 18, 2024

  • g_slist_prepend does a zeroed allocation and then fully initializes the result, which wastes a small but measurable amount of time (memset is abnormally slow on wasm, and we use g_slist a lot, so this does show up in profiles)
  • when the interpreter generates code for wrappers it always optimizes them, and as a result exception-handling methods and constructors tend to get inlined into every wrapper. this PR globally disables interp inlining of all methods on Exception and its derived types, since it is pretty safe to assume that they won't be called in hot paths. for my test application this reduces the number of generate_code invocations during startup from 862 to 802, a reduction of 60. It's possible this might be too aggressive.

) {
if (m_class_is_exception_class (klass->parent))
klass->is_exception_class = 1;
else if (!strcmp (klass->name, "Exception") && !strcmp(klass->name_space, "System"))
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

@lambdageek lambdageek left a 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 (with InnerException) that could be considered "hot".

src/mono/mono/metadata/class-init.c Show resolved Hide resolved
@kg
Copy link
Contributor Author

kg commented Apr 23, 2024

"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 (with InnerException) that could be considered "hot".

OK, I'll restrict it to not inlining ctors, that should still help a lot with wrappers

@kg
Copy link
Contributor Author

kg commented Apr 23, 2024

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.

@kg kg merged commit bbf3a4a into dotnet:main Apr 23, 2024
76 of 80 checks passed
matouskozak pushed a commit to matouskozak/runtime that referenced this pull request Apr 30, 2024
* Optimize out an unnecessary memset under g_slist_prepend
* Don't inline constructors of Exception or its descendants into interpreter method bodies
michaelgsharp pushed a commit to michaelgsharp/runtime that referenced this pull request May 9, 2024
* Optimize out an unnecessary memset under g_slist_prepend
* Don't inline constructors of Exception or its descendants into interpreter method bodies
@github-actions github-actions bot locked and limited conversation to collaborators May 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants