vscode-pull-request-github: Performance regression when creating pull requests on a repo with lots of branches

Repo:

  • In VSCode, execute a git push to a GitHub enterprise repo with thousands of branches (we have >6,000, someone should clean this up, but that’s orthogonal).
  • Press the button to create a Pull Request.
  • VSCode saturates CPU and takes ~60-90 seconds for the Create Pull Request dialog to appear. At that point, it still takes another 30-60 seconds for the “merge into” branch to update to master.

Expected behavior:

  • This should only take a few seconds (which was the case until a few weeks ago, as far as I can tell).
  • Executing this on a repo with fewer branches (e.g., with 300 branches) is nearly instantaneous.

Other notes:

  • Running latest VSCode and extension (1.78.1, plugin version v0.64.0) on an Intel Mac with 32GB RAM.
  • The merge into doesn’t show all of these 6,000 branches, just a subset.
  • I had previously filed a bug a year ago that master would not appear on a repo with lots of branches; some special logic was added so that it does appear (https://github.com/microsoft/vscode-pull-request-github/issues/3303).
  • While master does eventually appear, it feels like it’s actually fetching the entire list before dropping most of them.
  • The plugin otherwise performs fine.

Let me know if I can collect any more data — this is driving me nuts, so help is appreciated 😄

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 17 (9 by maintainers)

Commits related to this issue

Most upvoted comments

I agree, caching is a pain and would not be ideal. I almost never change the branch, but it wasn’t clear on the UI that I could just use the defaults. 🤔 I’ll give it a try and report back.

(The other issue is the CPU peg is just annoying, as everything slows down. I’d be a huge fan of defaults, and then populate everything else if you drop down the branch list. But I’ll give more feedback after my next PR.)

Thanks @janakjjp for the additional details. I found a case where we’re listing branches way too many times. I’m making a fix for it and I’ll let you know when it’s available in the pre-release build of the extension.