Performance of dragging into another branch very slow inside monorepo

[tomcru]

Hi, thank you for the beautiful work on Gitbutler! 🙏

I've been stumbling into some performance issues, especially when dragging changes between branches. I believe the larger the codebase, the longer this takes. Since it felt very snappy & fast in smaller projects.

https://github.com/gitbutlerapp/gitbutler/assets/35841182/2655c4ca-1de6-4b0c-8bd8-3a9713d6da0a

Not as noticeable, but committing also feels like it has more lag:

https://github.com/gitbutlerapp/gitbutler/assets/35841182/69f4ed6a-fe11-411c-86a9-48765825b9d3

Edit: Clicking the red "Update" button next to the Workspace Tab also experiences 2-3 seconds lag (after download/it disappears) until the branches on the right side update.

[LucaKaufmann]

I've been noticing the same, seems to be related to the latest 0.10.25 release. Before that any actions were much quicker

[ryanm101]

Mines always been slow on an M1 Mac

[krlvi]

Hey, sorry for the slowness! When you have a moment, could try out the latest app version (0.10.27) or newer? There was a fix that we landed that was specifically addressing performance issues in repos with many tracked files. Let me know how it goes

[laurenkt]

I'm on 0.10.28 with a relatively large monorepo (~10K branches, 1K weekly commits, 100+ contributors), and I find actions in the UI can take a very long time with no visual indicator they are in progress (or sometimes a brief visual indicator then a long time to take effect). E.g. about 30-40 seconds.

For example, recording below:

• Small change is committed
• Takes about 20 seconds of "commit" button having a spinner and the it stops
• Another 15 seconds with zero indication in the UI that anything is happening before the changes actually show
• Then click "Undo" to go back
• Zero indication anything is happening, after about 30 seconds the change is undone

https://github.com/gitbutlerapp/gitbutler/assets/1607874/d5ca94aa-5845-4a25-94e0-0244cec64045

[marryton007]

I'm on master, and made a very big monorepo, it contains all projects from AOSP. It makes very slow by all actions, drag and drop to create new virtual branch, delete useless virtual branch, etc., it almost doesn't work anymore.

[orirawlings]

I'm also experiencing something similar.

Version 0.10.28 (20240326.101627)

I'm trying out GitButler for the first time on a small to medium size repo. Though the repo has multiple commits with zero parents, if that matters (I noticed the refs/heads/gitbutler/integration reference ends up pointing to one of the zero parent commits).

GitButler is very slow to notice file changes and dragging changes between virtual branches is nearly unresponsive. I don't have any githooks configured on the repository that might be adding their latency to operations.

git-sizer output:

$ git sizer
Processing blobs: 3567                        
Processing trees: 3543                        
Processing commits: 4255                        
Matching commits to trees: 4255                        
Processing annotated tags: 98                        
Processing references: 124                        
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Biggest checkouts            |           |                                |
| * Maximum path depth     [1] |    12     | *                              |
| * Maximum path length    [1] |   118 B   | *                              |

[1]  46a5ace031ce13f7ca85c8824bc7522fcac7ad2f (1e7bd4c64407c7e247a19ea314d76512f8379fcf^{tree})

$ git rev-list --max-parents=0 refs/gitbutler/main | wc -l
       4

I'm on a 2.6 GHz 6-Core Intel Core i7 MacBook Pro with 16 GB 2400 MHz DDR4.

[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

[krlvi]

I am keen to hear from you folks if the more recent builds of the app are helping with the larger repos you guys are working with. If you have time to test it out, it would be super helpful 🙏

[Comnir]

In my case, I didn't see much change since I started using Gitbutler (around 3 weeks). Operations (new virtual branch, commit, push, moving files between branches) take 15+ seconds.

Is the application collecting such timing anywhere that I could rely on, instead of my occasional measurements?

The repository I'm working with has aroun 500 branches, 500 weekly commits, 200 contributors, 30K files (result of git ls-files).

[Comnir]

I'm not sure what's the contributing factor, but at the moment the same operations take less than 10 seconds. Maybe it's related to the calculation mentioned in a discussion here by @krlvi ? this is where we compute the diff in relation to the branch head

During the day (2+ hours from now) the repo is active and my branches gets behind the target branch.

[develar]

It takes several minutes to move a commit to another virtual branch. 0.14.32. How do I can report performance issue with traces or some info?

Monorepo size 90GB, 1,867,123 commits.

[develar]

It took 4 minutes and 17 seconds to move the commit. As you can see on the CPU timeline, there appears to be a bug — we observe CPU usage spikes. Most of the time it’s around 100%, and only occasionally does it reach 1600%. This was measured on a Mac Studio M1 with 128GB RAM, 2TB SSD, and a 20-core CPU (4 energy-efficient cores).

I recorded the trace using Xcode’s Time Profiler. I really like the tool and would be happy to help with resolving this issue (and any related ones). https://drive.google.com/uc?export=download&id=1azm3WbPtJMGVtzh1Gp1oGp8ADfLZ7_zt

[Byron]

Thanks so much, this is fantastic, and I will definitely come back to your offer of receiving more instrumentation from your repository! It's like the final boss, so it will take some tries to beat it, but we will get there :).

I perused the instruments save-file and despite most of the time is contributed by 'old' code (with gitbutler_ prefix), ~31s are coming from new code (i.e. but_). In there, 17s go into a merge-based integration check which is slow, and most definitely has to be done as a second pass in the background to speed this up. Maybe there can also be improvements to it, I don't know enough about it to know for sure.

14s are related to cherry-picking, which might just be the time it takes to do the work. However, within it, there are 12.6s of fetching objects from the git object database, and that is something that would be sped up in future by caching gix::Repository objects, and their in-memory object cache with them. That way, repeated operations would be much faster until the cache is evicted after some time. This is only meaningfully possible once the transition to gitoxide is (mostly) complete though.

If we assume that the time needed to perform the work on the repository might genuinely be, say, 10s, then in a final step the UI would have to be able to convey progress better. Maybe it could even show which commit it's working on while it rebases multiple commits, one at a time. Endless possibilities, and maybe a progress bar would already do the trick, after all the system knows ahead of time which commits will be rebased.

Even though I can't promise immediate improvements, they will happen over time as the old code is replaced by new one, and there we'd definitely want to look into ways to get to a point where it's as fast or faster than Git would be in the same situation.

[Caleb-T-Owens]

@Byron I was wondering if you might have any insight on whether this has now been improved, given the performance improvements to signing and your recent workspace work?

[Byron]

This seems to be happening mostly in gitbuter_branch_actions (according to the instruments screenshot), so I think performance is still similar.