Search code examples
ubuntunpmyarnpkgwindows-subsystem-for-linuxwsl-2

Why is WSL extremely slow when compared with native Windows NPM/Yarn processing?


I am working with WSL a lot lately because I need some native UNIX tools (and emulators aren't good enough). I noticed that the speed difference when working with NPM/Yarn is incredible.

I conducted a simple test that confirmed my feelings. The test was running npx create-react-app my-test-app and the WSL result was Done in 287.56s. while GitBash finished with Done in 10.46s..

This is not the whole picture, because the perceived time was higher in both cases, but even based on that - there is a big issue somewhere. I just don't know where. The project I'm working on uses tens of libraries and changing even one of them takes minutes instead of seconds.

Is this something that I can fix? If so - where to look for clues?

Additional info:

  • my processor: Processor AMD Ryzen 7 5800H with Radeon Graphics, 3201 Mhz, 8 Core(s), 16 Logical Processors

  • I'm running Windows 11 with all the latest updates to both the system and the WSL. The chosen system is Ubuntu 20.04

  • I've seen some questions that are somewhat similar like 'npm install' extremely slow on Windows, but they don't touch WSL at all (and my pure Windows NPM works fast).

  • the issue is not limited to NPM, it's also for Yarn

  • another problem that I'm getting is that file watching is not happening (I need to restart the server with every change). In some applications I don't get any errors, sometimes I get the following:

    Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'
    Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'
    Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'
    Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'
    
  • npm start in an empty (freshly initialized) create-react-app takes ages to render something in the browser in WSL and when executed from GitBash - I can see stuff in 2-4 seconds

  • it is possible that's it's purely a WSL problem, but it just hurts the most when using NPM/Yarn


Solution

  • Since you mention executing the same files (with proper performance) from within Git Bash, I'm going to make an assumption here.

    This would be explained (and expected) if your files are stored on /mnt/c (a.k.a. C:, or /C under Git Bash) or any other Windows drive, as they would likely need to be to be accessed by Git Bash.

    WSL2 uses the 9P protocol to access Windows drives, and it is currently (See Footnote) known to be very slow when compared to:

    • Native NTFS (obviously)
    • The ext4 filesystem on the virtual disk used by WSL2
    • And even the performance of WSL1 with Windows drives

    I've seen a git clone of a large repo (the WSL2 Linux kernel Github) take 8 minutes on WSL2 on a Windows drive, but only seconds on the root filesystem.

    Two possibilities:

    • Move the project over to somewhere under the WSL root, such as /home/username/src/. You should see an immediate, drastic performance improvement.

    • If possible (and it is for most Node projects), convert your WSL to version 1 with wsl --set-version <distroname> 1. I always recommend making a backup with wsl --export first.

      (Side-note: Unfortunately, WSL1 hasn't been updated in many years now. It's still an option, but as more issues in compatibility creep up, it's becoming more difficult to recommend this as a solution)

      And since you are making a backup anyway, you may as well just create a copy of the instance by wsl --importing your backup as --version 1 (as the last argument). WSL1 and WSL2 both have their uses, and you may find it helpful to keep both around.

      See this answer for more details on the exact syntax..


    Footnote:

    There may be some hope for improvement in this area based on recent developments. Patches for 9P have been released upstream which are reported to provide a significant performance boost. See this Github thread comment (and the parent thread) for more information.