Bad Performance in Pull Request File Tree

[joshuambg]

Select Topic Area

Bug

Body

This is a topic that has been documented in the community postings. I can't find anyone from GitHub that answers.
#10830
#33663

Large PRs with lots of files crash GitHub PRs. This is a real problem that needs to get on GitHub's planning board. Use the latest version of any browser. The problem is with the GitHub feature.

• Create a PR in GitHub with lots of files
• Try using the PR UI and PR file tree

Expected

• Fast and responsive UI

Result

• Browser tab can crash
• Browser freezes
• Scrolling clunky
• Chrome warns about slow unresponsive page

[borbudak-jadbio]

Any updates on this?

Even with only a couple hundred changed files Github code review can be extremely slow, to the point of it being almost unusable. The file tree search feature is also unusable. It takes ~10 seconds just for the cursor to appear once clicked, and typing/searching is even worse.

[themanciraptor]

As a workaround, you can use Firefox. Using Firefox, my old intel mac (6c, 16GB ram) renders large pr's pretty much lag-free while a few of my coworkers' apple M2's running chrome are freezing and lagging like crazy.

[CoenWarmer]

If you have more than 3k changes the UI just informs you it won't show you the remainder. C'mon Github, can't we do better than that?

[EdmondsZinc]

Still nothing on this one? How is Chrome being left out here?
I can confirm FireFox does appear to be a valid workaround. I just tested my PR and 2000 files is unusable in chrome but works fine in Firefox... womp.
You can't even expand the file tree width to see longer file names... pretty sad.

[alexandru-pap-osf]

Firefox works. Currently i have 2k files in a single PR, and I could open it so fast in Firefox.
Thanks for sharing the info.

[andreieftimie]

I used to switch from Safari to Chrome for a small performance boost on huge PR's.

Today Chrome is also choking. I am literally unable to review large PR's :(

[udlose]

I am also having this problem. We had a refactor that could only be done in a single PR w/o breaking the code in the repo. We had ~2,200 files changed in the PR. Why isn't there some sort of paging that exists?

[mpiggott]

Even a couple hundred files renders the UI extremely slow - filtering a tree with 200 entries shouldn't require locking up the browser for 10-seconds.

[crobinson-expl]

I'm having the same issue over the last week. A PR with just 307 files has taken me days to go through. Just marking a file as viewed takes around 5 seconds. If I have to click to load the diff (on files down past some file count threshold, even though they are small), then that's another 8-10 seconds. I have reviewed much larger PRs in the past that have not had these performance issues.

[george-of-croton]

i agree. I have an 800 hundred liner im trying to review and im getting multi-second lag on text input when writing review comments.

[jeremy-hunter]

For whatever reason Firefox handles reviewing a 3000 file PR just fine while chrome and safari are unusable.
Chrome says the memory heap for the PR on first load is 66MB, Firefox has the memory heap at ~450MB on load - maybe it's just a browser trying to conserve memory

[crobinson-expl]

A team member who uses the Brave browser let me know that they aren't experiencing the same issues, so I tried it out. Marking files as "viewed" is much snappier, but the time to being able to type in anything on a code comment seems about the same.

I noticed in the browser developer tools network tab that Edge makes many posts to https://api.github.com/_private/browser/stats whereas Brave doesn't do this (Brave left, Edge right):

I opened a ticket with GitHub Support on Friday but haven't received any update yet.

[crobinson-expl]

@jeremy-hunter Thanks for the Firefox info! I tried it there and it works great, even better than it does in Brave. Everything is responsive and usable like it used to be in Edge.

[milivojsa]

I can confirm that Firefox works great. Here's my pull request:

Chrome was stuck when I switched to the Files changed section while Firefox works like a charm.

I compared memory usage. Chrome comes up to 2GB, while Firefox is most of the time 0.7 - 1GB on the same page.

[zgavin1]

I have a pretty mild PR compared to some of these examples (1200 files, 1700 changes) and Chrome outright crashes, and firefox seems barely any better if at all.

[Blafasel3]

Feels like this gets worse with every Github update. Please fix this, this has the potential to make people move to other tools.

[ValentinGurkov]

I've been using mostly Vivaldi except when I need to review PRs because it lags there. For viewing PRs I use Chrome but it's lagging now there too.

The PR is not that big, 3,700 additions, 1800 removals. I've worked with much larger PRs without lag in the past.

[Sinarab]

I'm having the same issue here using Chrome. I tried using Firefox as a temporary solution to this lag situation, and it works only partially. Marking items as 'viewed' is fine, but searching for comments through the 'jump to conversation' feature doesn't work on both crashing the app.

Hope someone can solve this issue asap. 🤞

[Jakoban2411]

Still a huge issue. I've been using Brave and for PRs with >1000 files, despite filtering out to have only ~100 files, there's a huge lag, the Ui is unresponsive, Brave keeps asking me to kill the tab.

[paul-vd]

I can also confirm tested today with a PR of 2600+ it was snappy on firebox, but really slow on chrome.

on FF the only thing a little slow is when adding a comment to a line of code, but still much better than chrome.

[vmendiola]

Just experienced this today with a PR having ~800 files changed. Sadly, it is unbearable to work with.

[nlvedwin]

Same issue here it's super slow and making everything laggy. If you use firefox to view the changes it works perfectly fine

[joaopedrodcf]

The experience in web with PRs with lot of changes >300 it's terrible! The issue is that the all list is being loaded, at least in mobile we do have lazy loading there that does help with performance

[ovargas]

I have a merge request with 392 changed files. To try to improve performance, I’ve added the following patterns to my .gitattributes file to disable diffs:

vendor/** -diff
protobuf/** -diff
**/mocks/** -diff

While the UI no longer displays diffs for these files, it is still slow to load. It would be nice to:

• Automatically mark all files matching these patterns as Viewed, or have a way to do it in bulk.
• Have an option to exclude those files from the list entirely so I can focus on the remaining files in the PR.
• Improve the navigation and the loading per folder or similar.

[hichemfantar]

I really wish this part of github was open source, atleast then motivated independant devs can analyze the problem and push a fix by themselves.

[ChristianOellers]

Having the same issue in MacOS Chrome 131. For about 500 changed files, it's impossible to open even a Pull Request. Plus, just opening one, I would not expect or need an immediate diff to be visible.

Some ideas for an optimized UI:

1. Can't we just remove the auto-preview of the diff and make it opt-in or available on toggle?
2. If the displaying logic is inverted, I can also imagine the 'filter by filetype' tool, that really optimizes the performance, to work in the opposite way -> Toggle on what to see, not off what to remove

This really would need a change – The web UI is completely useless for large changes. Given the logical structuring of the project, making smaller Pull Requests is not an option, and large changes are a common requirement.

🙏

[JulianKingman]

376-file PR, mutiple second delay in Safari. Firefox is reasonably snappy, but I still get blank spots when scrolling where it takes it a minute to catch up. Also I don't think it's unreasonable to expect all the file names to load immediately and be searchable, regardless of the size. We're not talking about that much data here, are we? Even a big PR is probably in the 10's of megabytes...

[zcoffin86]

Same issue here. 54 Files changed, +640 -621. Chrome is unbearably slow, but Firefox has no issue. Looking forward to Chrome being usable again.