Where
src/ui/state.rs:718, inside compute_grouped_rows:
// Sort groups alphabetically by process name for stable ordering
group_stats.sort_by_key(|a| a.0.to_lowercase());
What
slice::sort_by_key does not cache the extracted key — it invokes the key closure on every comparison, which for a merge sort is O(N log N) calls. Here the closure allocates a fresh lowercase String each call, so sorting N process groups performs ~N·log₂(N) heap allocations instead of N.
compute_grouped_rows runs on every regroup in the Overview grouped view (a to toggle grouping, plus refreshes while grouping is active), so this is on the render/update path, not a one-shot.
Why it matters
For a host with, say, 64 distinct processes that's ~64·6 ≈ 384 String allocations per regroup where 64 would do. The per-frame cost is modest but it scales with process count and recurs every refresh.
Suggested fix
Swap to slice::sort_by_cached_key, which calls the key function exactly once per element, stores the keys, and sorts those — N allocations, cached:
group_stats.sort_by_cached_key(|a| a.0.to_lowercase());
Identical ordering (same key, same comparison), strictly fewer allocations. No behavior change.
Where
src/ui/state.rs:718, insidecompute_grouped_rows:What
slice::sort_by_keydoes not cache the extracted key — it invokes the key closure on every comparison, which for a merge sort is O(N log N) calls. Here the closure allocates a fresh lowercaseStringeach call, so sorting N process groups performs ~N·log₂(N) heap allocations instead of N.compute_grouped_rowsruns on every regroup in the Overview grouped view (ato toggle grouping, plus refreshes while grouping is active), so this is on the render/update path, not a one-shot.Why it matters
For a host with, say, 64 distinct processes that's ~64·6 ≈ 384
Stringallocations per regroup where 64 would do. The per-frame cost is modest but it scales with process count and recurs every refresh.Suggested fix
Swap to
slice::sort_by_cached_key, which calls the key function exactly once per element, stores the keys, and sorts those — N allocations, cached:Identical ordering (same key, same comparison), strictly fewer allocations. No behavior change.