perf(ui/state): use sort_by_cached_key for grouped-process sort to stop re-allocating the lowercase key per comparison #352

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.