Optimize EventSource.GetGuid (NetEventSource)

[EgorBo]

When I was looking at #120288 rerpo which is just a simple console app with some Socket server & listener, I noticed a huge chunk of time is spent in NetEventSource::.cctor (Linux-x64 and I run the app without dotnet-trace or any env.vars). In that cctor most of the time is spent inside EventSource.GetGuid that is obtaining custom attributes (presumably over this type)

Here is the GetGuid impl:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 367 to 379 in a2dc727

	public static Guid GetGuid(Type eventSourceType)
	{
	ArgumentNullException.ThrowIfNull(eventSourceType);
	EventSourceAttribute? attrib = (EventSourceAttribute?)GetCustomAttributeHelper(eventSourceType, typeof(EventSourceAttribute));
	string name = eventSourceType.Name;
	if (attrib != null)
	{
	if (attrib.Guid != null)
	{
	if (Guid.TryParse(attrib.Guid, out Guid g))
	return g;
	}

Is this something we can avoid "GetCustomAttributes" for and replace with some static map for BCL types?

PS: this is not the root cause of #120288

[jkotas]

Duplicate of #28290

[dotnet-policy-service]

Tagging subscribers to this area: @tarekgh, @tommcdon, @steveisok, @pjanotti
See info in area-owners.md if you want to be subscribed.

[EgorBo]

Ah, indeed!
cc @MihaZupan in case if you're interested in duplicates where your bot didn't mark it as such

[MihaZupan]

Looks like it flagged these as candidates, but all fell below the confidence heuristics.

• EventSource use of EventAttribute triggers dynamic methods in attribute usage #90405
• NativeRuntimeEventSource is too slow initialized #60963
• Add EventSource guid ctors for non-reflection creation #28290

Could be something to improve in the prompts

[EgorBo]

@jkotas this call seems to trigger ICU, I wonder if we can avoid it for ASCII-only type names

Presumably, ICU will most likely be loaded during the startup anyway for most apps, but seems like in this particular case it has no need

[jkotas]

I wonder if we can avoid it for ASCII-only type names

It would be safe to avoid it only if IsAsciiCasingSameAsInvariant returns true. IsAsciiCasingSameAsInvariant requires ICU...

ICU will most likely be loaded during the startup anyway for most apps

Right.

I think it is more interesting to figure out what needs to happen to generate this guid at build time.

[EgorBo]

Another bottleneck (unrelated): https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/Net/Sockets/SocketErrorPal.Unix.cs#L34-L130

Such static Dictionary initializations lead to a slow cctor with tons of Add() calls.
It's not the first time I see this problem, perhaps, we can do something for it e.g. on the Roslyn side?