-
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
EventSource use of EventAttribute triggers dynamic methods in attribute usage #90405
Comments
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsFor an empty Main method, and enabling DOTNET_JitDisasmSummary, we see all of these:
EventSource is looking for On my machine, this is costing ~10% of time-to-Main. When I disable the dynamic method approach, startup improves by ~5ms.
|
Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsFor an empty Main method, and enabling DOTNET_JitDisasmSummary, we see all of these:
EventSource is looking for On my machine, this is costing ~10% of time-to-Main. When I disable the dynamic method approach, startup improves by ~5ms.
|
One approach to addressing some of this is to implement #75357 which would share previously generated IL if the signature is the same and the method is not virtual. Otherwise, there are other options to consider such as detecting the startup phase in the runtime, and having reflection respect that so it doesn't generate the invoke stubs. |
@stephentoub does the logging here happen because we're enabling |
It's not related to DOTNET_JitDisasmSummary; the JIT handles that directly, not managed code. EventSource is unrelated to that.
Invariably on Windows there's something somewhere on the box that's enabled an ETW session, which then causes every .NET app to trip over this, with NativeRuntimeEventSource being created on the startup path. |
Moving to 9.0 however I'll investigate a solution now and we can always backport. The regression occurred in v7 (not v8).
Another approach is to determine if the ETW logging during startup is necessary. |
@stephentoub how was this measured? I tried launching corerun against simple console app and didn't see any improvments when only using interpreted invoke. Typical perf result like this:
|
With Jit results showing fewer items:
AFTER
|
Linking related issue #85791 |
What are you measuring that's only taking 5ms? That's not coreclr startup.
IIRC, I built once with main and once with the codegen code path commented out, and then used Measure-Command to time many empty console app invocations. |
Possible design that is extensible:
|
For an empty Main method, and enabling DOTNET_JitDisasmSummary, we see all of these:
EventSource is looking for
[Event]
on a type usingGetCustomAttributes
, which uses MethodInfo.Invoke to populate the attribute, and since there's more than one attribute, the setters all get invoked twice, triggering the MethodInfo.Invoke to use reflection emit and dynamically generate a method to handle each setter.On my machine, this is costing ~10% of time-to-Main. When I disable the dynamic method approach, startup improves by ~5ms.
The text was updated successfully, but these errors were encountered: