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.

🌲 🔮 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: 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. 👎 Fixed. 👍

☁️ ☀️ **[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: 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.