Initializing JS/TS Features is extremely slow with WSL and node_modules

[Vigasaurus]

template info added by @mjbvz

TypeScript Version: 3.6.2

Search Terms

• Wsl
• updateOpen
• perf

Original report below

---

From my testing - this issue seems to only be related to WSL (maybe 2.0) and node_modules together.

In Insiders v1.39.0 on a fresh install there were no issues on a specified project of mine (about 1GB, 60MB node_modules), as well as a smaller project (no node_modules, only about 15MB).
Once loaded into WSL with Remote WSL extension, a small project (no node_modules, only about 15MB) worked perfectly. The same first project (about 1GB, 60MB node_modules), didn't load (over 15 minutes).

EDIT: It ended up working after 29 minutes. I can maybe share the entire tsserver.log privately (once I scrub it) if needed.

[Vigasaurus]

Email with scrubbed tsserver.log sent.

[mjbvz]

Thanks! The line

Perf 154  [7:37:56.218] 0::updateOpen: elapsed time (in milliseconds) 716929.7271

explains why this is taking so long. I'm moving this issue upstream to TS but it could be a wsl issue as well.

[sheetalkamat]

Seems like the node_modules directory is big and because Linux doesn't support recursive directory watching we have to traverse whole directory and create those watches to handle the situation. Note that even if we did not watch node_modules here for closed script infos that are part of the project, we wont be able to avoid this as we would need to watch node_modules for the failed lookups during module resolution..

Info 52   [7:7:1.899] DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project:  WatchType: node_modules for closed script infos in them

Info 53   [7:36:45.857] Elapsed:: 643958ms DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project:  WatchType: node_modules for closed script infos in them

Info 54   [7:36:46.122] DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project: /mnt/c/Users/%username%/Documents/Github/MyProject/client/path/to/a/file.json WatchType: Failed Lookup Locations

Info 55   [7:36:46.123] Elapsed:: 0ms DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project: /mnt/c/Users/%username%/Documents/Github/MyProject/client/path/to/a/file.json WatchType: Failed Lookup Locations

[RyanCavanaugh]

@sheetalkamat let's chat about this one sometime. Curious what you think our next steps should be

[ApexWeed]

Running into the same issue under WSL using either typescript or typescript@next.

Host OS: 1809 (17763.615)
Guest Kernel: 4.4.0-17763-Microsoft # 379-Microsoft Wed Mar 06 19:16:00 PST 2019 x86_64 GNU/Linux
Typescript: 3.6.3 / 3.7.0-dev.2019.09.14
Node: v12.10.0

tsserver is being polled via tsuquyomi in vim 8.1.

Project load with typescript: Elapsed:: 850708ms ~14m
Project load with typescript@next: Elapsed:: 1039636ms ~17m

I noticed that instead of scanning just the include directory specified in tsconfig.json and node_modules it's also scanning the entire root for files. Log indicates it has watches scattered across ProgramData, Program Files, Users, Windows, and even extending to setting up watchers for external drives via /mnt/f. Performance is fine once initial load completes.

Also appears to be ignoring the tsconfig entirely as the logs list all project files under inferredProject1 and 0 files under the project for tsconfig.json. Doesn't appear to be intended behaviour according to the wiki.

This is a small project with only 66 files, ~3500 lines of ts/tsx files and 193 MiB of node modules so shouldn't be taking anywhere near this long to load. All project files are located in subdirectories of C:\Projects / /mnt/c/Projects.

Happy to provide logs privately if required, for both 3.6.3 and 3.7.0-dev.

[andreialecu]

Seeing the same issue here on WSL2.

Elapsed:: 278645ms DirectoryWatcher:: Added:: WatchInfo: zzz/node_modules 1 undefined Project:  WatchType: node_modules for closed script infos in them

node_modules is 815MB and has 77593 files.

I've also created microsoft/vscode#87921 before finding this issue, might be more information there.

[andreialecu]

This issue is probably also exacerbated on WSL2 by microsoft/WSL#4197

Putting the files on the native linux filesystem of wsl (on ext4) instead of getting to them through NTFS does improve things GREATLY:

Info 122  [14:14:45.198] Starting updateGraphWorker: Project: /home/aandrei/projects/zzz/tsconfig.json
Info 123  [14:14:45.234] DirectoryWatcher:: Added:: WatchInfo: /home/aandrei/zzz/node_modules 1 Project:  WatchType: node_modules for closed script infos in them
Info 124  [14:14:46.347] Elapsed:: 1113ms DirectoryWatcher:: Added:: WatchInfo: /home/aandrei/zzz/node_modules 1 Project:  WatchType: node_modules for closed script infos in them

[DaveBolt]

I am having the slow initialization problem.
I am not using WSL.
I have a PC running Ubuntu 18.04.
I have a VirtualBox VM running Ubuntu 18.04.
I have a PC running Windows 10 Pro 1909.
The problem can be seen on both my Ubuntu PC and Ubuntu VM, but not on Windows itself.
When I first installed VSC on Ubuntu, with an Ionic project that did not yet have the node_modules folder, everything seemed fine.
When I ran 'npm i' which creates the node_modules folder and populates it, VSC advised me that there were not enough handles and that I could exclude folders from watching or increase the availability of handles.
The node_modules folder is included in the default list of folders to ignore watching.
If the ignore list is working correctly, why should I get a message about the lack of handles when I populate **/node_modules/**?
(Side note. The entries for folders to ignore are like:
**/node_modules/**
and the notes say to prefix with ** or use the full path, but nothing about the ** at the end of the path).
I tried adding the complete path, like:
/home/Projects/projectname/node_modules/**
to the files.watcherExclude but No improvement.
Note: The Ubuntu installations of VSC I am using are provided via Snap. Not sure if it is relevant.
PS Sorry about the previous post. Lack of Coffee caused me to make a mistake in my testing :(

[sheetalkamat]

Needs ignoreFile and ignoreDirectory in watchOptions as hint to compiler to ignore watching cretain directories and files all together.

[airtonix]

Seems like the node_modules directory is big and because Linux doesn't support recursive directory watching we have to traverse whole directory and create those watches to handle the situation. Note that even if we did not watch node_modules here for closed script infos that are part of the project, we wont be able to avoid this as we would need to watch node_modules for the failed lookups during module resolution..

Info 52   [7:7:1.899] DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project:  WatchType: node_modules for closed script infos in them

Info 53   [7:36:45.857] Elapsed:: 643958ms DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project:  WatchType: node_modules for closed script infos in them

Info 54   [7:36:46.122] DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project: /mnt/c/Users/%username%/Documents/Github/MyProject/client/path/to/a/file.json WatchType: Failed Lookup Locations

Info 55   [7:36:46.123] Elapsed:: 0ms DirectoryWatcher:: Added:: WatchInfo: /mnt/c/Users/%username%/Documents/Github/MyProject/node_modules 1 Project: /mnt/c/Users/%username%/Documents/Github/MyProject/client/path/to/a/file.json WatchType: Failed Lookup Locations

Dont host mount stuff into wsl.

Always operate completely within wsl.

vscode-wsl extension makes this trivial