Repository navigation
Add EventSource guid ctors for non-reflection creation #28290
Description
Activity
Related discussion: dotnet/coreclr#16054 (comment)
re the discussion;
protectedmakes it a little less visible thanpublicand it isn't providing anything more problematic than what is already exposed via the ability to set the Guid via theEventSourceAttribute; other than that going via the slower reflection path.The fundamental problem with this change is that it promotes something (forcing people to use GUIDS in EventSources), that we really don't want people to do (GUIDS are really supposed to be hidden and uninteresting).
Now if there was a important reason, then maybe we do this bad thing, but we should do some due-dillegence first (lets see if we can fix the perf without doing violance to the code base).
Fundamentally, the GUID is DERIVED from the STRING name given to it (or part of the attribute), via a GenerateGuidFromName, method. Thus dropping the GUID parameter should only cost you that method (all the other reflection should be avoidable). From your traces this is a small amount, and looks like it could be made smaller with some tweeks to that method. This seems like a better approach.
Finally, we should be very careful with startup TIMES, as often it is the case that the FIRST time for APIs is significantly larger than all others. Thus you spend time fixing one place only to have it pop up somewhere else. Moreover, many of these methods are generic (use of Guids, use of Culture, use of Reflection), where it is unlikely that non-trivial programs don't also touch them (and thus incur the FIRST time penalty).
Thus I would like to insure we have first pursued all the options that avoid new ugly APIs. I would first review the profiles to see if ALL eventsource construction take similar time (they should, unless there are startup effects), and get a handle on the non-one-time costs. Minimize those first (which may be optimizing GenerateGuidFromName). After that determine if the one-time costs are likely to be hit anyway and it was simply EventSource that was 'first' (I am suspicious about this with respect to the reflection costs). We can then look at what our options are about eliminating those costs (since like I said the only REAL work that should be done is GenerateGuidFromName).
The workload to consider start-up time most for optimizing would be likely be Azure Functions/AWS Lambda as first response cold start is paid close attention to here, also Azure Web Apps without "Always On" switched on as then you pay the startup cost continuously (assuming low traffic site).
Its less significant in other areas; though new workloads like Desktop startup it may be more significant, but I imagine there is lower hanging fruit in for those.
To be clear, I am not doubting that there are important startup scenarios, or even that EventSource startup is important to optimize and that changes woudl be good. Only that we should look first for solutions that don't force users to trade off simplicity for performance, and that we believe that we are not just 'pushing' the cost somewhere else.
and get a handle on the non-one-time costs. Minimize those first
Had a go dotnet/coreclr#21832, dotnet/coreclr#21720, dotnet/coreclr#21729, dotnet/coreclr#21765 also added the Guid to RuntimeEventSource dotnet/coreclr#21714 and cleaned up some of the startup costs from EventPipe dotnet/coreclr#21718 and Environment dotnet/coreclr#21715
Waiting for the AspNetCore repo to pick up a runtime from this year to see if any of it makes a meaningful impact to startup-time/time to first response time (from cold):
This is good stuff @benaadams thanks for pursuing this
Waiting for the AspNetCore repo to pick up a runtime from this year to see if any of it makes a meaningful impact to startup-time/time to first response time (from cold)
Anything interesting here, @benaadams?
Seems to be going the otherway
Unfortunately the flow of the runtime into aspnet is a bit slow, so is hard to bisect what changes the increases relate to as its a very large range.
Looks like there are other issues for the increased startup dotnet/aspnetcore#8836
16 remaining items
I have edited the API proposal to follow the template and marked this as ready for review.
Reacted by Egor BogatovI'm fine exposing the Guid constructor.
I want to mention invoking the public API
EventSource(string eventSourceName)is sufficient to avoid most of the cost here. The difference betweenEventSource(string)andEventSource(string, Guid)is that the Guid constructor allows skipping GenerateGuidFromName. In @benaadams trace above GenerateGuidFromName is ~10% of the cost.We flipped the string and Guid parameters (so the
base()call starts with the name, not the GUID); otherwise looks good as proposed.namespace System.Diagnostics.Tracing; public partial class EventSource { protected EventSource(string eventSourceName, Guid eventSourceGuid); protected EventSource(string eventSourceName, Guid eventSourceGuid, EventSourceSettings settings, string[] traits = null); }
@jkotas should we go ahead and re-use corelib's source generator in other BCL libs now that the ctor is approved? I believe none of our EventSources use anything other than
EventSourceSettings.EtwManifestEventFormat(to address the concern raised during the API review).and then think about how we can expose the source generator for public without extra/new attributes? (it might require another API review?)
Sounds good to me. Do you plan to work on it?
Sounds good to me. Do you plan to work on it?
if you planned to work on this - feel free to grab it, otherwise I can take a look later this week 🙂
All yours
- locked and limited conversation to collaborators
on Dec 17, 2025
Background and motivation
Public EventSource constructors perform a lot of reflection to compute the name to register EventSource with, and compute SHA1 hash to compute the registration GUID. The proposed API enables generating the name and GUID via a source generator instead.
This source generator exists as internal for Corelib today. This proposal changes
internalEventSource .ctors that take Guid and name toprotectedAPI Proposal
API Usage
The API is expected to be used by source generator. Example of generated source:
Alternative Designs
No response
Risks
No response
The non Guid .ctors cause a lot of reflection to look up the Guid and name from the applied attribute and for first use a lot of Jit compilation of the reflection methods:
Which if it is in the startup path directly impacts startup times.
For coreclr they can use the internal .ctors dotnet/coreclr#21714, dotnet/coreclr#16054, dotnet/coreclr#16060
However there are still many corefx, aspnet and other app model
EventSources that get triggered on startup and cannot use these .ctor overloads (e.g.Microsoft-Diagnostics-DiagnosticSource,Microsoft-System-Net-Sockets,Microsoft-System-Net-NameResolution,Microsoft-AspNetCore-Hosting,Microsoft-Extensions-DependencyInjection) and directly impact startup time:/cc @jkotas