Git Integration (especially the changed file picker) is Slow in Large Monorepos

[ShiromMakkad]

Summary

When you use -g to open the picker for changed files, the files take so long to load that it's practically unusable. git status on the CLI is much faster, but I believe our company runs an internal version of git that caches the result. It would be great if helix could cache the result of this file picker.

Also, opening new files is noticeably slower in a large repo. The git gutters as you're typing still work well though.

Reproduction Steps

Press <space>-g and it will load for a long time.

Or open a file and it will take over 0.5 secs compared to instantly before.

Helix log

Can't provide due to it being a company laptop, but I checked the log. There's nothing that appears useful.

Platform

macOS

Terminal Emulator

Ghostty

Installation Method

brew

Helix Version

25.07

[Abdillah]

Could you provide more info about the estimate size of your repository involved?

Size of directories

$ du -sh .git
$ du -sh .

Also, when you do git status -uall --porcelain=2 how many files listed? That's likely the factor of the slowness.

[ShiromMakkad]

❯ du -sh .git
 19G    .git

❯ du -sh .
 36G    .

❯ git status -uall --porcelain=2

No files listed. Even when I do have changes, it's under 15 files.

There's a lot of effort put into the repo itself to make sure git status can run quickly (like structuring .gitignores differently), and we have an internal git reimplementation, but this is a huge repo. There are a couple things that Helix could do to help with this:

1. Caching for <space>-g. Hopefully there's a way to use caching to speed up opening new files too.
2. If you disable git gutters in a project, it shouldn't do a lookup for git information when opening files.

I'd be willing to raise PRs.

[RoloEdits]

Would you be able to build from source to see if there are any changes on master? A while back there was a flag enabled for gix that enables some multi threaded operations and some internal caching. This could improve diffing.

[ShiromMakkad]

I wasn't able to install Helix from source on my work Mac due to security policies, so I ran both helix 25.07.1 and the latest master on a Linux machine with the same repo. I found that going from Mac -> Linux gave a huge git performance increase especially with <space>-g (going from multiple minutes to 10s of seconds). The ARM Linux machine has 16 cores and 64GB of ram compared to the M4 Mac Pro which has 14 cores and 48Gb of Ram. On Linux, even on 25.0.7, the slowness of opening files is gone. I'm not sure if that's something happening locally on my mac, or is a Helix on Mac performance issue. The newest master gave another sizable performance improvement. I found that <space>-g takes 3-5 seconds now, which is usable. But, reopening the menu doesn't change that speed at all.

I still think both the changes I proposed above are useful, especially the <space>-g caching.

[RoloEdits]

I believe #9951 attempts to add this.