Can the GetProcessesByName method reduce the number of arrays and Process objects created?

[lindexi]

Description

As written in the code, GetProcessesByName first calls GetProcesses to obtain all processes of the machine, and then filters the process name

        public static Process[] GetProcessesByName(string? processName, string machineName)
        {
            if (processName == null)
            {
                processName = string.Empty;
            }

            Process[] procs = GetProcesses(machineName);
            var list = new List<Process>();

            for (int i = 0; i < procs.Length; i++)
            {
                if (string.Equals(processName, procs[i].ProcessName, StringComparison.OrdinalIgnoreCase))
                {
                    list.Add(procs[i]);
                }
                else
                {
                    procs[i].Dispose();
                }
            }

            return list.ToArray();
        }

But in fact, we can filter the process name in GetProcesses in advance.

        public static Process[] GetProcesses(string machineName)
        {
            bool isRemoteMachine = ProcessManager.IsRemoteMachine(machineName);
            ProcessInfo[] processInfos = ProcessManager.GetProcessInfos(machineName);
            Process[] processes = new Process[processInfos.Length];
            for (int i = 0; i < processInfos.Length; i++)
            {
                ProcessInfo processInfo = processInfos[i];
                processes[i] = new Process(machineName, isRemoteMachine, processInfo.ProcessId, processInfo);
            }
            return processes;
        }

If we do this, we can reduce the allocation length of the Process array and create some Process objects in the GetProcesses method

[ghost]

Tagging subscribers to this area: @eiriktsarpalis
See info in area-owners.md if you want to be subscribed.

[danmoseley]

@lindexi is this just a general observation, or is this causing performance impact in your own application?

[lindexi]

@danmosemsft this is just a general observation.

[danmoseley]

@lindexi thanks, but unless something is self-evidently inefficient, we would need perf numbers to motivate increasing the complexity in this way. I will close this: feel free to reopen if you have such numbers. We recommend use of Benchmark.NET. I do agree with @jkotas that I do not think you will see a benefit.

[danmoseley]

Apologies - I mixed this up with the other perf issue you opened (for registry). I have not evaluated this one.

[adamsitnik]

@lindexi would you like to send a PR?

[felipepessoto]

If we want to reduce memory allocation, we may want to filter the process name all the way through the NtProcessInfoHelper.GetProcessInfos, for Windows, where we have SYSTEM_PROCESS_INFORMATION.ImageName:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Win32.cs

Line 346 in f4d3913

private static unsafe ProcessInfo[] GetProcessInfos(ReadOnlySpan<byte> data, Predicate<int>? processIdFilter)

and similarly for Linux:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Linux.cs

Line 187 in 6072e4d

internal static IEnumerable<int> EnumerateProcessIds()

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.