Kdash is too slow compared to kubectl or k9s

[KaminariOS]

The major reason that forces me to keep using kubectl is the latency.

Almost all kubectl commands are instant, but kdash shows visible latency(1 ~ 2 seconds).

Especially logs, they are printed line by line, visibly.

Is there any insight into it?

I may be able to contribute to the fix.

[KaminariOS]

> strace -c kdash
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ------------------
 91.25    0.050021         337       148         3 futex
  2.17    0.001191          10       109        14 openat
  1.14    0.000625           8        75           write
  1.03    0.000563          14        39           mmap
  0.88    0.000484          24        20           clone3
  0.83    0.000457          17        26           mprotect
  0.76    0.000417          10        41           rt_sigprocmask
  0.67    0.000365           3        95           close
  0.57    0.000314           3        92           ioctl
  0.26    0.000145           5        25        17 statx
  0.16    0.000089           5        16           read
  0.03    0.000018           2         7           brk
  0.03    0.000018           3         6           rt_sigaction
  0.02    0.000013          13         1           socketpair
  0.02    0.000011           2         4           lseek
  0.02    0.000010           2         4           fstat
  0.01    0.000008           4         2           epoll_ctl
  0.01    0.000008           2         3           getrandom
  0.01    0.000007           3         2           pread64
  0.01    0.000007           2         3           sigaltstack
  0.01    0.000006           1         4           munmap
  0.01    0.000006           3         2           fcntl
  0.01    0.000006           3         2           sched_getaffinity
  0.01    0.000005           5         1           poll
  0.01    0.000005           5         1           eventfd2
  0.01    0.000005           5         1           epoll_create1
  0.01    0.000005           2         2           prlimit64
  0.01    0.000003           3         1           set_tid_address
  0.01    0.000003           3         1           set_robust_list
  0.00    0.000002           2         1           arch_prctl
  0.00    0.000002           2         1           rseq
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           mremap
  0.00    0.000000           0         1           execve
  0.00    0.000000           0        11         9 newfstatat
------ ----------- ----------- --------- --------- ------------------
100.00    0.054819          73       749        44 total

[KaminariOS]

(Generated by Codex)
• Lock contention, not syscalls, is what you feel

• The strace snapshot is 91% spent in futex, i.e. threads blocking on mutexes rather than doing I/O. kdash grabs the global App mutex on every UI draw and on every network update;
  when the network thread updates a resource the UI thread sits in a futex, and vice‑versa. (Locks live in src/app/mod.rs around state access and every set_items, and are taken in
  src/network/mod.rs for each response.)
• On first render (and on every namespace change/refresh) kdash fires a “cache everything” burst of 20+ list calls (cache_all_resource_data in src/app/mod.rs:595-621). The single
  network worker processes them sequentially. While it holds the mutex to write each result, the UI is blocked, so latency piles up to “sum of all requests” instead of the fastest
  one.
• Periodic refresh is polling-based: updates go out only every poll_rate (default 5000 ms) ticks (src/app/mod.rs:699-739). k9s/kubectl use watches, so they render almost immediately
  on server events; kdash naturally lags by up to 5s even without contention.
• Namespace switch (src/handlers/mod.rs:242-246) triggers the same full sweep, so changing ns regularly causes seconds of blockage and a futex storm.
• Extra overhead: refresh recreates the client by shelling out to kubectl cluster-info (src/network/mod.rs:76-94), adding another API call and process spawn that k9s/kubectl don’t do
  on routine refresh.

Fastest wins to close the gap

1. Stop full sweeps: on first load/namespace change, fetch only the active pane; prefetch others lazily or in parallel tasks.
2. Move to watches/reflectors per resource (kube-rs watcher/reflector), so updates stream without 5 s polls and without serial list calls.
3. Minimize mutex time: write state in a background task and swap in completed snapshots (e.g., with tokio::sync::watch or an Arc<RwLock<…>> scoped to the specific table) so UI draws
   aren’t blocked by network writes.
4. If refresh is needed, skip the kubectl cluster-info subprocess unless the API call actually fails; reuse the existing client when only context changes.

[deepu105]

I have made some significant architecture changes, can you try now. Reopen if still an issue