Staging and unstaging files feels unresponsive

[nathansobo]

Not sure this is due to shelling out to perform these actions, but I'm really noticing the lag when selecting a file to stage or unstage in the changed files list. I think we need to do something to make it feel more responsive... I favor making changes in the UI optimistically and rolling them back if there's an error. We could also show some kind of loading state but I don't think that's ideal.

[BinaryMuse]

We've made a bunch of changes to the async queue and the model observer to improve performance. Other than #386, are you okay with closing this?

[smashwilson]

Based on some Slack conversations with @nathansobo I'm guessing the answer is "no" 😉 He's suggested that we target <100ms as an acceptable time window to produce a visible response to user input, in accordance with Google's RAIL performance model. We're currently hovering around ~500ms, and that'll just get worse on large repositories or slower machines.

Offhand I can't think of anything else but #382 that would reliably bring us under that time window - but I also think #382 is reasonably attainable for public launch if we scope it to staging and unstaging operations.

[smashwilson]

Just to brainstorm some other avenues to explore:

1. nodegit/libgit2 was already explored and was a no-go; see the discussions in 🎬 nodegit 2: The Revenge of nodegit! 😱 #524 for details. Furthermore, in this case, the git status call in nodegit took much longer than shelling out.
2. Selective invalidation of Repository state based on a finer-grained view of filesystem events is something we haven't really looked into. For example, there's no reason to re-read the current branch if .git/HEAD hasn't been touched. The downsides here are (a) the most expensive call, git status, is also the one we'd need most often anyway, and (b) filesystem events are noisy and occasionally lossy, so we'd risk missing an event and displaying stale data.
3. Re-implementing selected git operations in pure node could whittle away at the number of times we need to shell out. Unfortunately, status would be call we'd need the most, and it'd be a beast to port properly and keep consistent with real git.

[nathansobo]

I agree about focusing on staging and unstaging files and hunks and 100ms response being the target. Google has research backing up my intuition that it feels unsettling to interact in a fine-grained way with interfaces that don't update at least that fast. Even if we have to change the color of the hunk or something to confirm it being clicked, I really think we need some sort of response so staging doesn't feel like swimming in molasses.

[smashwilson]

Automatic refresh (#560) is in. It helps somewhat, but I've noticed that on Windows this is really bad:

immediate-refresh.zip

The git apply --cached - operation there alone takes 120ms. I'll profile on my Mac on Monday to see how we're doing on that front.

#671 is up next in this effort.