cpptools extension loads slowly in vscode

[chongchai]

I ask the same question in vscode #45041

Env

• VSCode Version: 1.20.0
• OS Version: windows 7
• extension installed: ms-vscode.cpptools 0.14.6

My Case

I open a c++ project and press F5 to debug. But after pressing F5, it needs to wait 20 seconds to start debug process. So i check the startup performance and find the ms-vscode.cpptools use 20s to activate. I don't know whether it is normal.

Startup Performance Measurement :

OS: win32 (6.1.7601)
CPUs: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4 x 2394)
Memory (System): 3.99GB (0.97GB free)
Memory (Process): 199.38MB working set (199.45MB peak, 183.18MB private, 42.98MB shared)
VM (likelyhood): 0%
Initial Startup: false
Screen Reader Active: false
Empty Workspace: false

(index)	Topic	Took (ms)
0	"[renderer] window.loadUrl() => begin to require(workbench.main.js)"	423
1	"[renderer] require(workbench.main.js)"	707
2	"[renderer] create extension host => extensions onReady()"	565
3	"[renderer] restore viewlet"	46
4	"[renderer] restore editor view state"	0
5	"[renderer] overall workbench load"	196
6	"------------------------------------------------------"
7	"[main, renderer] start => extensions ready"	1726
8	"[main, renderer] start => workbench ready"	1350

(index)	startup	codeLoadingTime	activateCallTime	activateResolvedTime	activationEvent
vscode.emmet	true	147	6	0	"*"
vscode.git	true	186	24	0	"*"
vscode.merge-conflict	true	26	4	0	"*"
ms-vscode.cpptools	true	240	26	21300	"*"

Steps to Reproduce:

1. install ms-vscode.cpptools 0.14.6
2. open a cpp file
3. execute task "startup performance" to check the cpptools plugin activation stats

[sean-mcmanus]

Have you tried reproing this with our latest version 0.15.0? We do some one-time installation on the 1st run, but it sounds like this is occurring repeatedly? Our extension typescript is open source, so you may be able to step into the typescript debugger to see what it's stuck on. Our extension is expected to finish activating very quickly, within a second or so (we're not able to repro any issue).

Does the slowness repro if you activate via opening a C/C++ file instead of debugging? You can tell when our extension activates via the icons that appear in the bottom right.

@pieandcakes Any ideas what could cause the debugger to be slow to initialize?

[pieandcakes]

@sean-mcmanus I think the activateResolvedTime is the entire extension activation, not just the debugger. I have a feeling that it isn't the debugger causing the activateResolvedTime of 21300, and that it is doing all the other activation events too.

[sean-mcmanus]

Yeah, you're right, but I don't know of any language service code that could cause such a delay during activation -- we definitely had one bug that could cause this in 0.14.5, but this is the 1st report I've seen a problem with 0.14.6+. I think we need a repro or for the user to launch the extension from the source and provide us with a typescript call stack.

[pieandcakes]

You can comment out either of the activation calls and see which one is causing it. AFAIK it shouldn't be the debugger because on activation, we are only making 2-3 API calls back to VSCode to provide configurations.

Could it be the download retry?

[chongchai]

@sean-mcmanus opening a C/C++ file, I see a red fire icon in the bottom right within a second. So activation is fast. I think activation time is euqal to codeLoadingTime + activateCallTime from the table in my first post. I check the command 'Developer: Show Running Extensions' and find the c/c++ plugin activation time is about 270 ms.

But activateResolvedTime is still about 20 sec.

I'll try v0.15.0 or try to debug the source to check the problem.

[chongchai]

seems to find the problem related to network.

My network is behind proxy. When I set the proxy in the settings.json as follows:

    "http.proxy": "http://xxx:xxx@proxy.xx.com",
    "http.proxyStrictSSL": false

the activateResolvedTime will be the normal 2 secs.

However, when I delete the proxy setting, the time will be up to 20 secs.

ps: I have set the proxy in the internet options and I can search and install extension in the vscode.

[sean-mcmanus]

We also download a very small config file called cpptools.json at the very end of the activation, so it looks like that's the cause (assuming it's not the 1-time download of OS files). We previously blocked activation on this, but it looks like it got moved to the end of activation -- is it still blocking something or just making activation ending look like it's taking a long time?

[chongchai]

I check the time for downloadCpptoolsJson.
If not set proxy, it needs about 20 secs to return timeout error.
if set, the time comes to 1-3 secs.

So I think finalizeExtensionActivation in processRuntimeDependencies is the main cause.

[chongchai]

cpptools.json file just contains:

{
    "intelliSenseEngine_default_percentage": 100
}

I didn't dive into the source code. So I'm confused about why the extension needs to download cpptools.json during activation.

@sean-mcmanus can you give me some explanation? Thank you in advance.

[sean-mcmanus]

We don't really need it now, but it could be used in the future. We used it in the past to selectively enable the IntelliSenseDefault for a certain percentage of users. Our intent was that users shouldn't be impacted by the download because it should occur asynchronously at the end of activation, but it looks like it's blocking debugging, so we should fix that.

[sean-mcmanus]

Should be fixed in https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.0-insiders . Let us know if you're still reproing it or if you discover any other regression with that so we can fix it before the final release next week.

[chongchai]

I use the v0.15.0 codebase and remove the return from the line return cpptoolsJsonUtils.downloadCpptoolsJsonPkg(); as you did in commit 42698a8.

The activation delay issue is fixed.

[sean-mcmanus]

Ah, okay, that should be the same.