Change:
*--------------------------------------------------------------------------------------------*/ import { localize } from 'vs/nls'; <ins> import { raceTimeout } from 'vs/base/common/async'; </ins> import product from 'vs/platform/product/common/product'; import * as path from 'vs/base/common/path'; import * as semver from 'semver-umd';

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.35, 1.36 OS Version: Ubuntu 18.04 Steps to Reproduce: lists all extensions takes 30 seconds to return, even if no extensions are installed I tried uninstalling all extensions, uninstalling VSCode (also deleting) and upgrading to the newest version, the behavior persists. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: N/A
Is there a way to profile the cli? It could be also that launching the cli might be taking time? Can you please check if it is taking same time in the UI? (Listing installed extensions)
Hi sandy081, listing extensions in the UI seems not to take longer than normally. At least when I click on the extensions icon I see all installed extensions without much delay.
Thanks. May I know the experience when you are launching VS Code from CLI?
Of course. I am automating the provisioning of development environments using chef and serverspec. Recently I noticed that verifying our setups using serverspec took significantly longer than it used to and identified vscode as being the reason.
Assigning to you since is not available. Looks spawning CLI is slow.
Spawning CLI is fast. Shutting it down seems to be slow. did I get it right that printing the extensions is instant... just that the process doesn't die immediately?
This is correct, it pretty much instantly prints all installed extensions (or none if none are installed) and then takes up to 30 seconds to return.
Is the time pretty constant? If you measure it a couple times using , are the numbers consistent?
Not really, here are a few times I called it. It seems to be consistently a multiple of ~ 5 sec though:
Interesting, I'm really out of ideas here...
Anything I can do to dig deeper into the issue?
Is it could be due to our telemetry flush while exiting?
Interesting . Can you edit the file distributed with code and change to and see if that helps?
That one change reduced the time from 20 - 30 seconds down to ~0.5 seconds!
Have you seen this before?
No. Based on the info here I suspected.

Also I was in that code recently.
Is there anything special about your network setup that you can think of which could delay reaching out to our telemetry service?
hm... not that I know of, all outgoing ports are open, incoming connections are blocked (unless connected via vpn). But until a few weeks ago there wasn't any issue.
Is it a work network, or a simple home network? Could you use Wireshark and detect that network connection to the telemetry service?
Simple workaround that doesn't involve modifying any files or settings: command line flag.
Verified that this is reasonable fast on my machine.