Commit preview freezes with large number of changed files

[DrafaKiller]

Version

0.16.10

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

When loading the preview of a commit with a large number of changed files, such as 500 files, the application completely freezes for a long time. When the "Changed files" preview is as "tree" it becomes almost unusable, however, when the preview is as "line" it is still slightly slow but much more usable.

We had a commit with 2,700 files and it completely froze the application whenever it was in tree view, to the point that we had to restart GitButler just to be able to use another branch. Luckly, we discovered that we could work around it for now by using the line view.

How to reproduce

1. Commit a change with a large number of independent file entries;
   • The content of the files shouldn't matter;
   • At least 500 different files;
2. Go to "Branches" in the GitButler application;
3. Select the branch of the commit (if not already selected);
4. Select the commit (if not already selected);
5. Select the preview to "tree" mode (if not already selected);
6. Look at the file structure preview, as it struggles to load and freezes the application.

You can use the powershell script to create 1,000 files:

for ($i = 1; $i -le 1000; $i++) {
    New-Item -Path "$i.empty" -ItemType File -Force | Out-Null
}

Expected behavior

The rendering of the preview shouldn't be this slow, but even if it is, it shouldn't freeze the application. Instead, it should show a normal "Loading..." without blocking, and be canceled when changing to another commit.

If that's not possible, a workaround should be to have a "Load Preview" button for commits with big changes, and warn that it can be slow while in tree view.

Demonstration

[DrafaKiller]

This issue could be related to #10841, although that issue is reporting having large number of merges listed in the branch, while this issue is about a large number of file entries in the commit's preview.

[Byron]

Thanks a lot for reporting!

I was already aware that the file list component is not fast, and gets way slower when the tree view is enabled.

But what's new is that the performance scaling seems non-linear, such that 500 files are still 'doable', but 1000 files are many times slower than 500 files, making performance unacceptable. It's easy to imagine how 2700 files in tree view can freeze the application.

https://github.com/user-attachments/assets/51561e96-0242-4c3c-957c-b480a2f9fcdc

To me, tackling this would be to make the performance scaling linear for the tree view, do you think this is possible @estib-vega ?