Faster way for performance monitor to get child processes #7574

JohnThomson · 2026-01-09T17:14:33Z

Typically takes a fraction of a second vs 5-10s for the old approach.

This change is

Typically takes a fraction of a second vs 5-10s for the old approach.

Copilot

Pull request overview

This PR optimizes the performance monitor's child process enumeration by replacing a slow WMI-based approach with a faster Windows Toolhelp32 API-based solution. The old implementation made multiple WMI queries per generation of child processes, taking 5-10 seconds, whereas the new approach takes a snapshot of all processes once and walks the process tree in memory.

Changes:

Replaced iterative, generation-by-generation WMI queries with a single snapshot-based approach using Windows Toolhelp32 API
Added fallback to WMI-based approach for non-Windows platforms or when the fast method fails
Refactored descendant process discovery to use breadth-first search with a parent-to-children map

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

src/BloomExe/Utils/PerformanceMeasurement.cs

Copilot · 2026-01-14T21:00:00Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                var snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
+                if (snapshot == IntPtr.Zero || snapshot == INVALID_HANDLE_VALUE)
+                    return map;


When CreateToolhelp32Snapshot fails, the function silently returns an empty map, which will result in no child processes being found. Consider logging this failure for diagnostics, as it could indicate a system issue or permission problem that might affect performance monitoring accuracy.

Not new or changed code. Don't want to mess with it.

Copilot · 2026-01-14T21:00:00Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                catch
+                {
+                    // If the fast Windows approach fails for any reason, fall back to WMI below.


The catch block silently swallows all exceptions when the Windows approach fails. Consider logging the exception for diagnostics to help identify why the optimized path failed and whether the fallback is being triggered frequently.

Suggested change

catch

{

// If the fast Windows approach fails for any reason, fall back to WMI below.

catch (Exception ex)

{

// If the fast Windows approach fails for any reason, fall back to WMI below.

Debug.WriteLine($"GetAllDescendantProcessesWindows failed; falling back to WMI. Exception: {ex}");

Copilot · 2026-01-14T21:00:01Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                    foreach (var childPid in children)
+                    {
+                        if (descendantPids.Add(childPid))
+                            queue.Enqueue(childPid);
+                    }
+                }
+


This foreach loop implicitly filters its target sequence - consider filtering the sequence explicitly using '.Where(...)'.

Suggested change

foreach (var childPid in children)

{

if (descendantPids.Add(childPid))

queue.Enqueue(childPid);

}

}

foreach (var childPid in children.Where(childPid => descendantPids.Add(childPid)))

{

queue.Enqueue(childPid);

}

}

Don't want to risk changing this. The current code is not difficult to understand, and I'm not 100% sure that there is no difference between checking when the pid is enqueued and checking when it is dequeued.

Copilot · 2026-01-14T21:00:01Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                    foreach (var childPid in children)
+                    {
+                        if (descendantPids.Add(childPid))
+                            queue.Enqueue(childPid);
+                    }


This foreach loop implicitly filters its target sequence - consider filtering the sequence explicitly using '.Where(...)'.

src/BloomExe/Utils/PerformanceMeasurement.cs

andrew-polk

@andrew-polk reviewed 1 file and all commit messages, made 1 comment, resolved 9 discussions, and dismissed @copilot[bot] from 9 discussions.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @JohnThomson).

src/BloomExe/Utils/PerformanceMeasurement.cs line 385 at r1 (raw file):

                }

                return GetAllDescendantProcessesWmi(parent.Id);

Seems like we should wrap this in a try with empty catch. We definitely don't want performance monitor causing user crashes (not that users are likely to have it on... but still seems worth it).

Copilot · 2026-01-14T21:04:26Z

@andrew-polk I've opened a new pull request, #7583, to work on those changes. Once the pull request is ready, I'll request review from you.

JohnThomson

Have taken some of the suggestions, not going to use the AI PR.

@JohnThomson made 7 comments and resolved 2 discussions.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @andrew-polk).

src/BloomExe/Utils/PerformanceMeasurement.cs line 385 at r1 (raw file):

Previously, andrew-polk wrote…

Seems like we should wrap this in a try with empty catch. We definitely don't want performance monitor causing user crashes (not that users are likely to have it on... but still seems worth it).

Done.

JohnThomson · 2026-01-20T17:19:16Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                catch
+                {
+                    // If the fast Windows approach fails for any reason, fall back to WMI below.


JohnThomson · 2026-01-20T17:19:16Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                    foreach (var childPid in children)
+                    {
+                        if (descendantPids.Add(childPid))
+                            queue.Enqueue(childPid);
+                    }
+                }
+


Don't want to risk changing this. The current code is not difficult to understand, and I'm not 100% sure that there is no difference between checking when the pid is enqueued and checking when it is dequeued.

JohnThomson · 2026-01-20T17:19:16Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                var snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
+                if (snapshot == IntPtr.Zero || snapshot == INVALID_HANDLE_VALUE)
+                    return map;


Not new or changed code. Don't want to mess with it.

JohnThomson · 2026-01-20T17:19:16Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                    listMOs.AddRange(
+                        new ManagementObjectSearcher(
+                            "Select ProcessId, ParentProcessId From Win32_Process"
+                        )
+                            .Get()
+                            .Cast<ManagementObject>()
+                    );


JohnThomson · 2026-01-20T17:19:17Z

src/BloomExe/Utils/PerformanceMeasurement.cs

+                    foreach (var childPid in children)
+                    {
+                        if (descendantPids.Add(childPid))
+                            queue.Enqueue(childPid);
+                    }


andrew-polk

@andrew-polk reviewed 1 file and all commit messages, and resolved 1 discussion.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @JohnThomson).

andrew-polk

@andrew-polk dismissed @copilot[bot] from 3 discussions.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @andrew-polk).

Copilot · 2026-01-20T17:22:44Z

@andrew-polk I've opened a new pull request, #7593, to work on those changes. Once the pull request is ready, I'll request review from you.

andrew-polk

@andrew-polk resolved 3 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @JohnThomson).

Faster way for performance monitor to get child processes

0b4c267

Typically takes a fraction of a second vs 5-10s for the old approach.

andrew-polk requested a review from Copilot January 14, 2026 20:54

Copilot started reviewing on behalf of andrew-polk January 14, 2026 20:55 View session

Copilot AI reviewed Jan 14, 2026

View reviewed changes

andrew-polk requested changes Jan 14, 2026

View reviewed changes

Copilot AI mentioned this pull request Jan 14, 2026

[WIP] Update performance monitor child processes implementation #7583

Closed

4 tasks

Post-review improvements

8cfa09d

JohnThomson commented Jan 20, 2026

View reviewed changes

andrew-polk approved these changes Jan 20, 2026

View reviewed changes

Copilot AI mentioned this pull request Jan 20, 2026

[WIP] Work in progress: Addressing review feedback on performance monitor #7593

Closed

andrew-polk approved these changes Jan 20, 2026

View reviewed changes

andrew-polk merged commit 17fafbb into Version6.3 Jan 20, 2026
2 checks passed

andrew-polk deleted the fasterChildProcesses branch January 20, 2026 17:23

Uh oh!

Faster way for performance monitor to get child processes #7574

Faster way for performance monitor to get child processes #7574

Uh oh!

Conversation

JohnThomson commented Jan 9, 2026 • edited by hatton Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

andrew-polk left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Jan 14, 2026

Uh oh!

JohnThomson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrew-polk left a comment

Choose a reason for hiding this comment

Uh oh!

andrew-polk left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Jan 20, 2026

Uh oh!

andrew-polk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

JohnThomson commented Jan 9, 2026 •

edited by hatton

Loading