Problem / Background

The current TUI render path repeatedly recomputes derived view data on every render pass:

• GPU lists are filtered and sorted again
• per-host CPU / memory / storage subsets are rebuilt
• GPU-only process filtering may clone process rows again
• process table formatting performs repeated per-row string work

This is especially costly in larger remote deployments or on hosts with many processes. Once #135 and #136 reduce unnecessary wakeups and lock contention, the next major CPU cost is the repeated regeneration of derived view state.

Proposed Solution

Introduce explicit caching for derived TUI view data and only invalidate it when the underlying inputs change.

The cache should be keyed by state that actually affects the derived result, such as:

• data_version
• current tab
• sort criteria / direction
• active process filter state
• terminal dimensions when layout-sensitive

Scope

Derived view caching

• Cache sorted GPU display lists instead of resorting them every render
• Cache per-tab / per-host filtered device subsets where practical
• Cache GPU-only process subsets instead of recloning them on each render
• Reuse stable metadata needed across frames (for example, user/session-local values)

Cache invalidation rules

• Invalidate caches only when dependent inputs change
• Ensure tab changes, sort changes, filter toggles, and collector updates invalidate the correct cache entries
• Keep cache behavior predictable and easy to reason about during debugging

Large-data validation

• Validate behavior with larger process counts and multi-node remote views
• Confirm that cached ordering and filtered results remain correct after data refreshes
• Add tests for cache invalidation behavior where feasible

Acceptance Criteria

• Unchanged frames do not re-run full GPU sorting / filtering logic unnecessarily
• GPU process filtering no longer clones the entire filtered process list on every render
• Remote host-specific subsets are reused when their inputs are unchanged
• Output remains correct across tab changes, sort changes, and data refreshes
• CPU usage drops further in large views compared with the post-Snapshot AppState before rendering to shorten the TUI critical section #136 baseline

Integration and Verification Requirements

• The implementation must be verified by actually running the affected code path and confirming the intended behavior works end-to-end
• Verification must cover both behavior correctness and the expected performance/responsiveness improvement for this issue
• The final result must be integrated into the existing project flow, not left behind as an isolated module, helper, or function that is not exercised by the real application path
• Completion is not satisfied by adding code alone; the change must be wired into the real local/remote TUI execution path and confirmed to be active in practice

Technical Considerations

• Cache ownership should align with the new snapshot/render architecture from Snapshot AppState before rendering to shorten the TUI critical section #136.
• Overly broad caches can become hard to invalidate correctly; keep the first iteration focused on the most expensive derived structures.
• This should be treated as the third implementation step, after the event-driven and snapshot-based changes are in place.