Slow for large repos

[asl]

Steps to reproduce:

• Grab a clone https://github.com/llvm/llvm-project
• Importing as a new project takes several minutes at least
• Then after selecting the main branch something takes minutes as well

[andrew-rosca]

Because many operations (e.g. creating a new virtual branch) take a very long time, and all controls remain enabled while an operation is in progress, the experience is very confusing with large repos.

For example, starting a commit takes several seconds. While the operation is in progress, there is no indication in the UI that something is happening in the background. This may cause you to click the "Start Commit" button multiple times, which results in the same operation being repeated and possibly errors.

A temporary workaround might be to disable the UI while an operation is in progress. It's not a great experience, but at least it avoids duplicate command issues.

[Byron]

That's very good to know, thanks so much for sharing!

Joining in @PavelLaptev, I thought I'd share I find this very interesting to solve from a UX perspective - buttons are surprisingly hard after all. If the operation is quick, the button might feel 'nervous' or flickery, so maybe it could enter a 'waiting' state only after a delay. Somehow I thought that if the user would click again within this delay, it could enter the 'waiting' state immediately to not let the user think nothing happen on click (somehow I feel UIs should always respond to a click, just to signal they received it and thus are working).

[PavelLaptev]

@Byron yep, that's a good idea. Let me check it first

[PavelLaptev]

@Byron I like the idea about timeout for "start commit" thing, in this case it wouldn't be "flickering".

In case you want to work, on this. The button has two props:

• disabled will only disable the button
• loading will disable the button and change or add the spinner icon

[PavelLaptev]

Made some edits to the project setup to prevent users from clicking on buttons while waiting: #4090.

However, I can't reproduce the "Start commit" issue because GitButler detects the changes I made (I cloned this repo: https://github.com/llvm/llvm-project).

Please see the video below where I compare GB to GH Desktop:

Screen.Recording.2024-06-16.at.01.06.47.mov

@Byron while we can add more loading states, the core issue is more fundamental. For large projects, GitButler is not usable with such load times.

[krlvi]

on the performance side of things, i have a pr that speeds things quite a bit #4091

[Byron]

@Byron while we can add more loading states, the core issue is more fundamental. For large projects, GitButler is not usable with such load times.

I agree, ideally any kind of loading time should be an edge-case (as GB is always fast enough to be instant). From a view of plain correctness, I think we should be able to assure that quick-clicks don't trigger a cascade of similar operations or that these operations are idempotent.

There is a part in me who thinks that if there was an abstraction for this, any 'action' button could be made to

• prevent interaction while the action is running
• show a spinner if it's running for too long
• become ready again once the action is complete (success or failure)

This would improve UX instantly while there are slowdowns, while still remaining useful in case we go from LLVM to monorepo with 3 million files.

With this being said, on internal channels I heard some operations may see a 10x performance improvement (🎉), but even with such a speedup, several minutes would still be many seconds.

About LLVM-Project load times

While at it, I couldn't resist to profile it as well and it burns large amount of time in git2::Repository::merge_base.

This is more of a note to self as I am collecting these issues at the moment. The UI is indeed unusable, as it times out and even when done quickly triggers the list_virtual_branches function again.

[krlvi]

Okay there is one more performance improvement which just landed with the latest patch release 0.12.5. Let me know how it works for you

[PavelLaptev]

@krlvi cool! Can confirm that's pretty fast now ⚡

Screen.Recording.2024-06-17.at.16.58.14.mov

[andrew-rosca]

I can also confirm the latest release is dramatically better!

[krlvi]

Keeping this issue open, but wanted to note that as of release 0.12.22 the performance on larger repos should be further improved

[andrew-rosca]

The last few releasees have worked great on the large(ish) repos I normally work with, with no noticeable impact on usability. There's still a slight lag when renaming branches, for example, but not enough to cause problems. From my perspective this issue is resolved.

If further improvements are possible and desirable, I suggest handling them as a separate story with measurable acceptance criteria.

[krlvi]

Thank you so much for getting back. Closing this now, feel free to open a new issue if you spot anything. Thanks