Extension likely caused X seconds of unresponsiveness

[Neme12]

I get this fairly often.

[drguthals]

Thank you @Neme12 for letting us know!

We are aware of this issue and are looking to resolve it in an upcoming release this month!

Once we release and you update, I will follow up to make sure this isn't still happening 👍

[jcansdale]

@bchavez said in #1539:

• Just a side note: Also seems there's a performance regression with v2.4.3.1737. Visual Studio seems to be putting the GitHub extension on blast. This is the second time I received the performance degraded message with v2.4.3.1737 installed: I didn't receive these warnings with the stock install v2.2.0.10 of the GitHub extension shipped with the VS 2017 installer. Ten seconds is kind of a big deal.

Correct. Just tested in a Win10 VM and the PRs load fine. However, I still get the performance regression in the Win10 VM: Maybe it's because these machines are running inside a VM.

@bchavez You're right, ten seconds is kind of a big deal!

Did you notice this unresponsiveness? If it hung for ten seconds, it would be difficult to miss!

I wonder what it counts as unresponsiveness? For example does refreshing the list of PRs (which should be happening in the background) count as unresponsiveness?

If it does, I'm surprised we haven't seen it while testing. 😕

[jcansdale]

I'm wondering if this might be related to #1542. My guess is that it isn't, because this other issue describes a "hang". When the "unresponsiveness" message appears, I don't think Visual Studio has actually hung.

[bchavez]

@jcansdale , I think, the message pertains to startup delay.

• The message only appears right after Visual Studio opens (even if there's no solution being loaded).
• Also, (separately and unrelated) Visual Studio tells me that ReSharper is "unresponsive" on startup on my main dev box, but I ignore them. R# is a heavy beast and I'm okay with that.

Are ya'll doing testing on super fast SSDs? Maybe, to reproduce the issue, try running Visual Studio and GH v2.4.3.1737 on slower hardware al la old-school 5400/7200 RPM HDDs.

I ran these tests on a Windows 10 VM with the VMDK on a Western Digital Green WD20EZRX. If you have an external mechanical drive somewhere, install a VM on that external mechanical drive and maybe you could start seeing a more pronounced delay in start time with v2.4.3.1737.

Also, maybe some old fashioned log messages with StopWatch might help. Soon as you get your first call fromVisual Studio, start the StopWatch and stop when you tell Visual Studio you're ready.

:evergreen_tree: :crystal_ball: PINES - Fate

[jcansdale]

Here's a relevant link: https://docs.microsoft.com/en-us/visualstudio/extensibility/how-to-diagnose-extension-performance

We should be doing this: https://docs.microsoft.com/en-us/visualstudio/extensibility/visibilityconstraints-element

[jcansdale]

@bchavez Most of our initialization is now done on a background thread (as recommend by the VS SDK team) and we try to stay off the Main thread as much as possible. From what I can work out we shouldn't be seeing these dialogs, but there must be something going on that I'm keen to get to the bottom of!

[jcansdale]

@Neme12, @bchavez, Hi folks, I have a new build that I'd very much appreciate if you could try: https://ci.appveyor.com/project/github-windows/visualstudio/build/2.4.4.1934/artifacts

In theory you should be able to update by simply opening the GitHub.VisualStudio.vsix file (as it will have a higher version than the one you have installed).

I think what's happening is that our extension gets the blame for the time it takes for VS to initialize its MEF cache (VS is a heavy user of MEF). Because the extension hooks into the Git SCC service, there is a good change it will be the first extension that wakes up and queries MEF (causing the cache to refresh after a new extension is installed). This can take around 10 seconds the first time VS is launched.

This update queries MEF on a background thread before installing it's UI on the Main thread. With any luck the background loading won't be held against us!

BTW, this is a different (but related) issue to:

• GitHub pane causes performance warning banner: #1550

Please could you close the GitHub pane before installing this update and launching VS.

Thanks!

[bchavez]

@jcansdale , Okay, I closed the GitHub window. Do you also want me to clear the MEF cache before installing the update too? IIRC,

AppData\Local\Microsoft\VisualStudio\15.0_d91727fb\ComponentModelCache

[jcansdale]

@bchavez,

If as I'm hoping, it is MEF related, clearing the cache should provoke the worst performance hit (VS loading all MEF assemblies that it knows about). If you could clear the MEF cache, that would be great. 😄

BTW, there's a handy extension to clear the MEF cache here: https://github.com/madskristensen/ClearComponentCache/

I end up using it more than I'd like. The MEF cache can be temperamental. 😉

[bchavez]

@jcansdale , seems okay now. Great job! :) Only thing I'm getting now is #1550 when I have the GitHub tab open:

---

---

Side note: Also, noticed this new problem with the "saved replies" on the GitHub website. Saved replies seem broken now. Just can't get a break from GitHub's web/design team. The keyboard shortcuts are all jacked up and when you click on a saved reply it doesn't print out the full saved reply. :-1: Fixed. :+1:

:cloud: :sunny: **[Bassnectar - Chasi...

[jcansdale]

@bchavez I've made some progress on the tool window issue. Could you have a look at this PR:

• Ensure that MEF is initialized using an old style non-async package: #1560

You can find the VSIX here: https://ci.appveyor.com/project/github-windows/visualstudio/build/2.4.4.1946/artifacts

Thanks again for all the investigation you've done!

[Neme12]

I am really sorry I don't have more info. I typically don't have the GitHub pane open and I think it doesn't repro unless I do that. I'll try to investigate this more.

[Neme12]

Actually I don't know... I haven't seen this very often recently, just occasionally.

[Neme12]

@jcansdale Has the change in the VSIX you recommended shipped already?

[Neme12]

I am able to reproduce this somewhat consistently with these steps - I got the popup 4 out of 5 times by

1. opening VS and making sure the GitHub window is open
2. opening Roslyn.sln - after a certain amount of time, I get the popup: even the time when I didn't, I noticed at least a 5 second unresponsiveness at one point. Actually even when not loading a solution but opening the GitHub window with pull requests loading, I experience very noticable UI delays.

[Neme12]

Hm, right now I got it after solution load even though the GitHub window was closed during and before loading the solution:

(is it possible this is because it was open at one point and then closed before I loaded the solution?)

[Neme12]

Ok, this is another repro for me.

1. open VS and make sure the GitHub window is open
2. close the GitHub window
3. open Roslyn.sln... after solution load I get:

[Neme12]

I just got it even if I only open the team explorer window before solution load

now I'm thinking it could be unrelated to whether I open either github or team explorer at all before loading the solution... but if that was the case I would have seen this a lot more often I think

[Neme12]

I'm sorry I don't know how else I could help

[Neme12]

Simply connecting to the repo from Team Explorer without loading the solution and then opening the GitHub window with loading pull requests does not reproduce the issue. It looks like it only happens after solution load.

If I open the solution after all this, I still get the popup:

[Neme12]

Given all this, I think my problem is completely unrelated to @bchavez because it doesn't happen after VS load or the github extension or window load, only after solution load.

[Neme12]

I just got 15 seconds after cloning the repo from scratch and then opening the solution.

[Irwest]

Hi, Was it resolved? I've disabled it and now i dont see my solution. Cannot find how to enable it again. Please HELP!!!

[Bazeloth]

1 year later im still experiencing this issue. What happened? It's really driving me crazy. I've disabled solution wide analysis and it somewhat helps, but its frustrating as hell.

[jcansdale]

@Bazeloth,

1 year later im still experiencing this issue. What happened? It's really driving me crazy. I've disabled solution wide analysis and it somewhat helps, but its frustrating as hell.

How consistent is this? Is there a particular repository it does this on?

I've seen this banner appear pretty randomly on extensions that aren't doing much (they really shouldn't be hogging the UI thread!). It's difficult to tell when it's a Visual Studio bug and when it's a GitHub extension bug. 😢

[Bazeloth]

It happens frequently. VS hangs whenever:

• i open a solution
• i switch branches

This notification only occurs are opening a solution from a cold boot as far as i can tell.