Introducing Environment.ProcessorUserTime & ProcessorPrivilegedTime

[tarekgh]

We are exposing runtime metrics to report statistics for GC, thread pool, JIT, lock contention, timer, and process time. The implementation of these runtime metrics will reside in the System.Diagnostics.DiagnosticSource library, where the Metrics feature is housed. However, to report ProcessorUserTime and ProcessorPrivilegedTime, we need to call Process.GetCurrentProcess().ProcessorUserTime and Process.GetCurrentProcess().ProcessorPrivilegedTime, which requires adding a dependency on the System.Diagnostics.Process library. This dependency introduces two problems:

• Cyclic Dependency: System.Diagnostics.DiagnosticSource is a low-level library, and adding a dependency on System.Diagnostics.Process creates a cyclic dependency chain: System.IO.Pipes > System.Net.Sockets > System.Net.NameResolution > System.Diagnostics.DiagnosticSource > System.Diagnostics.Process > System.IO.Pipes.
• Size Regression: Adding more dependencies to this low-level library will increase the size of AOT builds.

To avoid these issues, we propose exposing new properties in the Environment class to report the same information, thus eliminating the need for the System.Diagnostics.Process dependency.

Proposal

static class Environment
{
    ...
    public static ProcessCpuUsage CpuUsage { get; }
    ...
}

public readonly struct ProcessCpuUsage
{
    public TimeSpan UserTime { get; } // report TimeSpans that are identical to calling Process.GetCurrentProcess().ProcessorUserTime
    public TimeSpan PrivilegedTime { get; } // report TimeSpans that are identical to Process.GetCurrentProcess().ProcessorPrivilegedTime
}

Alternative Design

static class Environment
{
    // identical tocalling Process.GetCurrentProcess().ProcessorUserTime
    public static TimeSpan ProcessorUserTime { get; }

    // identical tocalling Process.GetCurrentProcess().ProcessorPrivilegedTime
    public static TimeSpan  ProcessorPrivilegedTime { get; }
    ...
}

Example

     ProcessCpuUsage processCpuUsage = Environment.CpuUsage.
     Console.WriteLine($"ProcessorUserTime: {processCpuUsage.UserTime}  ... ProcessorPrivilegedTime: {processCpuUsage.PrivilegedTime} ");
     
     // Or the alternative design will be 
     Console.WriteLine($"ProcessorUserTime: {Environment.ProcessorUserTime}  ... ProcessorPrivilegedTime: {Environment.ProcessorPrivilegedTime} ");

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[terrajobst]

Would the alternative design even work? Presumably these two values are linked so one would want to query them atomically, no?

[tarekgh]

@terrajobst

The alternative design is like what we are currently exposing from the Process class. But you have a good point as I expect more scenarios will need to snap the user and privileged time together.

https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.userprocessortime?view=net-8.0
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.privilegedprocessortime?view=net-8.0

[MichalPetryka]

Is there a reason for separate type instead of a tuple?