4 ms·

Would you mind elaborating (for those of us uninformed)

• yakz 4mo ago
  It's difficult to overstate how horrible the performance is.
• weird-eye-issue 4mo ago
  One example is that if you have a node modules folder on Windows and you try to delete it from WSL it can take 10 plus minutes whereas if you deleted it directly in Windows it would have just taken a few seconds Also if you try running Next js from files on Windows from WSL it takes minutes for each page to compile to the point that any local development is impossible so you would have to either run the Next JS server on Windows or move the files to WSL
  • rahkiin 4mo ago
    Anything with node_modules takes ages on my Windows machine, whether it is through WSL, Docker or direct, largely in part due to corporate filters, checks, anti-virus and malware protectors and endpoint control.
    • DanielHB 4mo ago
      Although the stuff you mention is true, it is not the only reason. NTFS is just notoriously bad at reading/writing tons of small files. It also has a lot of problems with locking files that are open by a process, if you have a rogue process reading your node_modules npm install or rm node_modules can hang until that process finishes. yarn2 keeps dependencies as tarballs instead of extracting them to disk, imported files get loaded from the tarball at runtime. Makes a massive difference in windows.
    • deleted 4mo ago
      [deleted]
• tonymet 4mo ago
  WSL2 is a VM based on a Windows virtual disk file (VHD). inside that VHD IO is quite fast , a couple degrees worse than native. /mnt/c is how you access your windows files, but it's slow like NFS (socket based). anything needing high IOPS will be dog slow e.g. compiles, file scanning, etc. the rule of thumb without the newest features is to copy work to/from /mnt/c into $HOME as needed.
• omcnoe 4mo ago
  /mnt/c is a mounted C: drive in WSL2, that allows WSL2 guests to read/write files on the Windows host. The mount is fine and speedy enough, but the underlying reads/writes turn into native NTFS reads/writes through Windows. NTFS file API is incredibly slow - high fixed overhead for initial file access. So patterns like node_modules with many small individual files (or compiling code in general) are much much slower on Windows or WSL2 /mnt/c due to the fixed overhead adding up over a large number of files. It's a ridiculous problem that has plagued Windows for years.
  • 0x1d7 4mo ago
    It's the file system filters that are an issue on Windows. It trades performance for extensibility. NTFS itself is a fast file system.
    • wahern 4mo ago
      eBPF has opened the door to such bloatware on Linux. Previously there was no easy, stable way for enterprise bloatware vendors to maintain complex file and subsystem filter and analytic modules. Now that market is exploding because of eBPF, and it's a big reason there's so much work around growing eBPF's capabilities.
    • throwa356262 4mo ago
      "NTFS itself is a fast file system" File access is significantly slower on Windows compared to Linux on the same hardware. You can run Linux inside a VM and it will easily beat the host OS in filesystem performance. If the problem is not NTFS, then it is in how the Windows OS uses it
      • tssva 4mo ago
        > If the problem is not NTFS, then it is in how the Windows OS uses it Isn't that exactly what the comment you are replying to is saying?
        • 0x1d7 4mo ago