Performance Optimization Needed for Large Monorepos in GitButler

[carlosalbadd]

I've been using GitButler for the past few weeks and have genuinely grown to love it. The tool significantly enhances my workflow, particularly when it comes to navigating branches, debugging, and managing changes through the apply/unapply feature.

While working with a large monorepo, I've noticed some performance challenges that I believe could be addressed to further improve the user experience for users with similar setups:

1. Rendering speed in large repositories: When working with my large monorepo, the app often experiences slow rendering, especially when inputting text in branch names or commit descriptions. It would be great if this could be optimized for smoother interaction with extensive codebases.

2. UI responsiveness with numerous files: In my large repository, when dragging file changes to another virtual branch, the app tends to freeze. Improving the stability during these operations for repositories with a high file count would be incredibly helpful.

3. Large repository optimization: While I understand the unique challenges presented by large monorepos, perhaps some specific optimizations could be made to enhance GitButler's performance in these environments? This could potentially include:

   • More efficient indexing
   • Selective loading of repository data

Despite these challenges, I want to emphasize that I find immense value in GitButler, even when working with my large repository. I'm even willing to consider a paid version of the product because of how useful it is to my workflow. I'm sharing this feedback in the hope that it might help prioritize potential improvements for users working with extensive codebases.

---

Thank you for creating such an innovative tool. I'm excited to see how GitButler evolves and look forward to continued enhancements in performance and usability, particularly for those of us working with large repositories.

[Byron]

Thanks so much for this collection of performance issues!

I'd hope that Rendering speed in large repositories can be improved as a UI-only adjustment - after all, there shouldn't be a real reason for it to be slow when the only thing that changes is the text that is entered.

Everything else is likely dependent on being as efficient as possible without wasting any cycles, to be able to scale at least linearly with size. On top of that, I'd expect that partial checkouts would help tremendously, even though I don't think they are supported yet.

gitoxide is built with partial checkouts and monorepos in mind, so any algorithm would be aware of partial checkouts which should help greatly with performance. The switch to it is planned, but there is still a lot of work ahead.