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.