Adds two columns to the Processes table (and rows to the inspector) next
to Memory, which is the physical footprint:
- RAM: pages currently in physical memory (ri_resident_size, from the
proc_pid_rusage call that was already being made).
- Compressed: the original size of the process's pages held by the
compressor, via task_name_for_pid + TASK_VM_INFO. This is also the
closest per-process swap figure: macOS pages out compressor segments,
not processes, and those stay counted here. Activity Monitor's
"Compressed Memory" and top's CMPRS report the same value.
Both need no privileges for the user's own processes; other users' and
system processes report 0, as the Memory column already did. Values match
top/ps within sampling noise; a full refresh of ~650 processes including
the extra call takes ~5 ms.
Memory, RAM and Compressed live in one @TableColumnBuilder property:
Table takes at most 10 columns per block, and inlining them also
exceeded the type checker's time limit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The window left open all day grew the app by ~360 MB in 24 h even after
the .tabItem fix. Isolating each piece in lab builds showed the growth is
the sum of several small framework leaks on macOS 26.6 that fire on every
view update: SwiftUI Table cell updates, AppKit text-cell KVO
dependencies (NSKeyValueDependency) and an ObservationRegistrar created
inside DesignLibrary. With the window closed every counter stayed flat;
minimized or fully covered, SwiftUI kept updating and kept leaking.
- WindowVisibility tracks whether any TopManager window is on screen
(occlusion state; the status item's host window is ignored).
- SystemMonitor records into an always-current LiveState and only
mirrors it into the @Published properties while something is visible.
Resuming publishes everything at once, so views catch up immediately.
Metrics history, alerts and the menu bar keep running while paused.
- MenuBarStatus carries the pre-formatted menu-bar strings, republished
only when the visible text changes.
- AlertCenter assigns healthScore/diagnosis only when they change.
- Monitoring now starts in applicationDidFinishLaunching instead of the
main window's onAppear, so it also runs when the app launches with no
window (state restoration after the window was closed).
Also fixes a visible bug: ProcessMonitor's lightweight refresh (2 of
every 3 fetches) emitted 0 for memory, CPU and threads instead of the
last known values, so ~90% of rows showed "Zero KB" most of the time.
Verified in an isolated lab instance: minimized or covered, all leak
counters stay flat while the menu-bar title keeps updating; a partially
visible window updates every tick. Growth while the window is actually
visible (~190 KB/min) is unchanged — those leaks are in Apple's
frameworks. 58/58 tests pass, including a regression test that fails on
the old code (472 of 487 own processes reported 0 memory).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- ProcessItem: disk read/write rate + cumulative bytes, energy-impact score,
executable path; equality now tracks energy/disk so the table refreshes
- ProcessMonitor: disk I/O + idle-wakeup rates from rusage_info_v4; full path
capture; on-demand KERN_PROCARGS2 args + PROC_PIDLISTFDS open-file count
- EnergyModel heuristic + pure ProcArgs parser (both unit-tested)
- ProcessView: sortable Energy + Disk I/O columns (icon folded into Name to stay
within SwiftUI's 10-column limit); Get Info (double-click / ⌘I) opens inspector
- ProcessInspectorSheet: live stats, path, args, open files, Reveal/Copy Path
- 10 new tests (32 total green); smoke: stable under CPU+disk load
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
