The very same thing as described by the OP is happening to me under a similar scenario: Ubuntu Linux using a workspace with some remote directories mounted locally using gvfs. Except that VS Code becomes unresponsive and I'm forced to kill its process to close it.
If I start a clean session and I create a new workspace adding back the same directories from the old one, I can work just fine, but as soon as I exit VS Code and I relaunch it, it happens again.

VS Code version 1.32.1 (.deb version 1.32.0-1551898681 from http://packages.microsoft.com/repos/vscode stable/main)

OS: Ubuntu Linux 18.10 X86_64

I'm experiencing the same issue here:

• VS Code Version 1.32.1
• Ubuntu 18.10 X86_64

When attempting to load a mapped drive mounted through sshfs the explorer window never even populates with folders -- I've been working with this large filespace in VS Code for two years now and this is the first version that showed any slowness at all loading it up, let alone being seemingly unable to load it entirely.

To test I even mounted a personal webserver's /var/www/ directory to the same drive and attempted to open it with VS Code and while the folders did eventually appear in the explorer this time, it took several minutes, and this is a server with about five small personal websites on it.

I've ended up reinstalling version 1.31 and I'm able to continue working.

According to #70143 this is not only from the explorer but also opening normal files.

People hitting this, are you all on the same OS?

@bpasero lookint at the comments I see two people on Ubuntu and one person on Windows_NT

Can people try to reproduce with our insiders builds: https://code.visualstudio.com/insiders/

Still happens (on Win10 x64) with insiders build 1.33.0 (d77d8d5).

Running debian 9. Purged 1.31 and installed 1.33 (insiders). No extensions.
Opened folder from mount via VPN. Populating file list (left pane explorer) takes about 2-3 minutes - just to list files in the root folder. Additional minutes to open any subfolder.
Clicking on a file and waiting to show in editor... too long. And I had to kill it because it stopped responding.

Can people just check if node.js 10.2.0 shows the same issue when trying to e.g. fs.readdir a remote folder?

I used this:

{
    let start = process.hrtime();
    fs.readdir("T:\\vm_sites\\", function(e, f) {
        console.log("Callback: ", process.hrtime(start), "Files: ", f.length);
    });
    process.hrtime(start);
}

The results were always around 40 µs for fs.readdir to return and around 36 ms for the callback to be called, with a list of 493 entries (the folder in question contains 487 directories and 6 files at that level).

Neither {withFileTypes: true} nor using fs.readdirSync changes the times significantly (± a couple ms).

Notice that T: is a network mapped drive.

@davidsantos-br thanks for testing, I forgot to ask people to try out our exploration builds that come with a much newer Electron/node.js version to see if it could help:

• macOS: Download
• Linux: Download
• Windows: Download

@bpasero tried code-exploration, same problem(s)

Mac OS host to SSHFS on Linux. Same issue.
What's weird is that this doesn't happen if I remove and create a new workspace (right after creating the new workspace).
It only has the constantly moving blue bar and fails to open files if I reopen a workspace to a large SSHFS filesystem.
It won't even load locally stored files after I close and relaunch the workspace.

Correction: it does eventually open files it just takes a long time.

Maybe about time that we get some profiling information to see where most time is spend.
Can you follow this wiki and post the results back here to understand more about why performance is so bad for you: https://github.com/Microsoft/vscode/wiki/Performance-Issues

Thanks!

Just to add I am also experiencing this issue on Windows 10 Home connecting via OpenVPN to a remote server running Ubuntu.

I've downgraded to VS Code 1.31.1 for now and that's working fine.

I tried one more thing today in code-insiders 1.33 - opening mounted folder on another server over cisco vpnc connection and it took some time to index all items (file explorer), but not nearly as long as over openvpn. Clicking on any file or subfolder opened it immediately.
Looks like there is a problem with openvpn

Hello,

Trying to reproduce the issue and upload the text file requested, produced empty files. I'm also suffering from this issue that appears to be VPN related since accessing the same folder from a computer on the same LAN works without delays. However I don't have 500 projects as the OP so I'm certain the root of the problem is still there.

Using either SoftEther VPN or OpenVPN makes things really REALLY slow without an obvious reason.

People that see this issue, are you opening the network folder directly (e.g. via File > Open Folder), or is it part of a multi-root workspace file you open? Does it reproduce if you use the UNC on localhost scheme, e.g. when opening a path such as \\localhost\c$\my_dir?

This also happens with large repos using GVFS . In case this is helpful - when the virtualization service is disabled (i.e. when GVFS is unmounted), the issue does not repro. However, when the virtualization service is active, it always repros, even on subsequent launches of VS Code.

EDIT: This is on VSCode 1.32 and 1.33.0-insider, and Windows 10

I was just debugging VSCode and expanded folder "X" in the explorer pane, and it appears that VSCode is enumerating files well outside of folder "X" (meaning not even within it).

For example:
I expanded the folder
"e:\repos\osNew\src\minkernel"
and vscode is enumerating
"e:\repos\osNew\src\base\PerfTest\MemRe\AppLifecycle"

i have an idea and will ask people to try a new build once its ready

Looking through the commits and debugging VSCode, I am wondering if these strict null checks changes somehow changed the decision of the file service on whether to enumerate all directories or just the one the explorer view is asking for:

a6c498b#diff-a63388ce79427f16181b4686359ff685

Debugging through VSCode certainly shows that when the explorer view asks to expand a directory, the entire workspace contents are enumerated.

Can people please try with this build if it still reproduces:

• Windows: Download
• Linux: Download

This build removes the changes from #67269 that for me put a lot of pressure right on startup due to extensive file scanning.

@bpasero the build seems to have fixed the issue for me

@bpasero this latest build (code-insider-1552583659, debian9) works for me as well

Awesome thanks for the quick turn around!

@bpasero This build greatly improved things. Opening the folder in a workspace or "open folder" makes eveyrthing open almost instantly even over VPN. I have a folder with over 1000 subfolders and this build needed about 20 seconds to open it which was great improvement since before I had to wait about 5 minutes.

Generally, the experience is still not the same as the local one but its a great improvement in comparison to other builds.

We verified it by the following steps:

• Open task manager
• Open \\localhost\c$ on windows using the latest Insiders that has the bug
• See that disk/CPU usage spikes a ton. Try to kill vscode, it won't die

Repeat the same steps with 1.32.3, see that disk/cpu doesn't spike and it's responsive very soon after starting.

Confirming that the latest insider's build from @bpasero resolved the issue under Linux, too.

Looks good to me on Windows 10 as well. Thanks for sorting this!

1.32.3 appears to have fixed it for me!