The window stops responding while a large account syncs, and nothing says that Sync all is running #167

New Issue

2026-11-10T23:47:51Z

james.maes commented

2026-11-10 23:47:51 +00:00

What happens

Reported by the owner while trying a 1.1.1-dev build with three accounts (78, 1 and 281 repositories):

While Sync all runs there is no way to tell. The only signs are the pane item's text ("Cancel sync all") and a small dot on the account that is running. The workspace on screen may belong to another account, where nothing moves.
The window stops responding when a sync starts, so it looks as if the app is broken.

Measured

A probe build (local bare repositories, the real git client, a watchdog that pings the window's thread):

Case	Result
Clone pass, 281 repositories, the syncing account on screen	23 stalls over 200 ms in 75 s, 11.6 s in total, longest 1.1 s. Repaints were starved for up to 8.3 s at the start.
Same pass, another workspace on screen	no stall
Update pass, the syncing account on screen	repaints starved for 1.4 s at the start
Showing an account with 281 repositories	the window does not answer for 1.0 to 1.3 s, every time it is shown

Where the time goes:

Every progress report is its own dispatcher callback. A clone reports each whole percent, so 281 clones are 28,662 reports. With the rows on screen they took 27.5 s of the window's thread (about 1 ms each, up to 214 ms); with the rows off screen, 12 ms in total. The cost is the bound row and chip updating, and a layout pass per report.
A table row costs about 20 ms to build (WinUI.TableView 1.5.0), and 59 rows are built for a viewport of about 20 because the list keeps two viewports of rows on each side.

Wanted

Progress reaches the window in batches (a few times a second, the latest state per repository), so a run of any size leaves the window responsive.
A status bar that is there for the whole pass: which account, which of how many, how many repositories done, a way to go to that account, and Cancel. It replaces the dialog at the end.
The activity log says when the window did not respond, for how long, and what was running.
Fewer rows built ahead of the viewport.

Not in this issue

The per-row cost of the table itself, and keeping a workspace's page instead of rebuilding it on every visit (measured: 0.3 s instead of 0.7 to 1.0 s). Both go with the shell work.
The wider activity log request (durations for every phase).

## What happens Reported by the owner while trying a 1.1.1-dev build with three accounts (78, 1 and 281 repositories): 1. While **Sync all** runs there is no way to tell. The only signs are the pane item's text ("Cancel sync all") and a small dot on the account that is running. The workspace on screen may belong to another account, where nothing moves. 2. The window stops responding when a sync starts, so it looks as if the app is broken. ## Measured A probe build (local bare repositories, the real git client, a watchdog that pings the window's thread): | Case | Result | |---|---| | Clone pass, 281 repositories, the syncing account on screen | 23 stalls over 200 ms in 75 s, 11.6 s in total, longest 1.1 s. Repaints were starved for up to 8.3 s at the start. | | Same pass, another workspace on screen | no stall | | Update pass, the syncing account on screen | repaints starved for 1.4 s at the start | | Showing an account with 281 repositories | the window does not answer for 1.0 to 1.3 s, every time it is shown | Where the time goes: - Every progress report is its own dispatcher callback. A clone reports each whole percent, so 281 clones are 28,662 reports. With the rows on screen they took 27.5 s of the window's thread (about 1 ms each, up to 214 ms); with the rows off screen, 12 ms in total. The cost is the bound row and chip updating, and a layout pass per report. - A table row costs about 20 ms to build (WinUI.TableView 1.5.0), and 59 rows are built for a viewport of about 20 because the list keeps two viewports of rows on each side. ## Wanted - Progress reaches the window in batches (a few times a second, the latest state per repository), so a run of any size leaves the window responsive. - A status bar that is there for the whole pass: which account, which of how many, how many repositories done, a way to go to that account, and Cancel. It replaces the dialog at the end. - The activity log says when the window did not respond, for how long, and what was running. - Fewer rows built ahead of the viewport. ## Not in this issue - The per-row cost of the table itself, and keeping a workspace's page instead of rebuilding it on every visit (measured: 0.3 s instead of 0.7 to 1.0 s). Both go with the shell work. - The wider activity log request (durations for every phase).

james.maes referenced this issue

2026-11-11 00:40:07 +00:00

The repository table follows the sync by default, and the Sync all status is one aligned row #168

james.maes referenced this issue from a commit

2026-11-11 00:56:24 +00:00

fix(app): the window stays responsive while a large account syncs, Sync all says where it stands, and the table follows the sync

james.maes referenced a pull request that will close this issue

2026-11-11 00:56:44 +00:00

fix(app): the window stays responsive during a sync, Sync all says where it stands, and the table follows the sync #169

james.maes referenced this issue from a commit

2026-11-11 01:51:03 +00:00

fix(app): the window stays responsive while a large account syncs, Sync all says where it stands, and the table follows the sync