Skip to content

feat: completion-order streaming (Branch 1 — kill head-of-line delay)#32

Draft
rsanheim wants to merge 1 commit into
rjs/git-all-ui-feedback-c07c9bfrom
rjs/git-all-completion-order
Draft

feat: completion-order streaming (Branch 1 — kill head-of-line delay)#32
rsanheim wants to merge 1 commit into
rjs/git-all-ui-feedback-c07c9bfrom
rjs/git-all-completion-order

Conversation

@rsanheim

Copy link
Copy Markdown
Owner

Branch 1 of 2 in the "make fetch feel fast" divide-and-conquer. This one evolves the sticky-footer printer; the sibling branch (rjs/git-all-tty-ratatui) explores a full ratatui TUI.

Stacked on the Phase 1 branch (rjs/git-all-ui-feedback-c07c9b, PR #31) so the diff here is just the completion-order delta: one file (printer.rs) + the doc.

Problem

The trace on git-all fetch over 104 repos exposed the real cause of "feels slow": the printer buffered finished rows behind the alphabetically-earliest unfinished repo.

  • first_exit_ms=2432 — first fetch finishes at 2.4s (network floor)
  • first_print_ms=9794 — but the first row didn't appear until 9.8s
  • max_ordered_wait_ms=10637 — worst repo waited 10.6s to display after finishing

So repos were completing but the screen looked stuck for ~7s. (No wall-clock regression — status benched identical to main, 3.85s vs 3.87s.)

Change

TtyTablePrinter now streams each repo's row the moment it finishes, tracking printed rows by index instead of a contiguous cursor. The live scrollback is in completion order; the pinned footer (counts, clock, in-flight list) is unchanged.

Non-TTY / redirected output is untouchedPlainPrinter keeps deterministic alphabetical order, so pipes and scripts stay stable.

Results (~/work status under a PTY)

metric before after
first_print_ms 771 (status) / 9794 (fetch) 225 (= first_exit)
delayed_repos 98 11
max_ordered_wait_ms 1592 1
total_ms 3641 3641

Verified

cargo test green (updated the buffering test to assert completion order), clippy/fmt clean. Driven under tmux with script/tty-lab — mid-run, a slow early repo (activities) is still in the footer's running list while six later-alphabetical repos have already streamed to scrollback. Clean rendering, no scrollback garble.

[cache-layer  ] clean          <- finished first, shown first
[agentic-dev  ] clean
[billing-svc  ] 1 untracked
[amion-api    ] clean
[backend-core ] clean
[data-pipeline] clean
----------------------------------------------------------------
SUMMARY  6 of 24 done | 6 running | 12 pending | 2.5s
running: activities, dashboard, edge-proxy, gateway, growth-tools, identity

The sticky-footer printer buffered finished rows behind the
alphabetically-earliest unfinished repo, so on a big fetch the first row
could lag ~7s behind the first completion (first_print_ms=9794 vs
first_exit_ms=2432) and a finished repo could wait up to 10s to appear.

TtyTablePrinter now streams each repo's row the moment it finishes,
tracking printed rows by index instead of a contiguous cursor. On
~/work status under a PTY: delayed_repos 98 -> 11, max_ordered_wait_ms
1592 -> 1, first_print_ms 771 -> 225 (= first_exit_ms), total_ms
unchanged.

Non-TTY / redirected output is untouched: PlainPrinter keeps its
deterministic alphabetical order, so pipes and scripts stay stable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant