5 ms·

Anyone with a Mac who can compare file system operations between Mac and WSL2? I jumped ship from Windows to Mac before WSL2 as it was just too slow to use. U

Anyone with a Mac who can compare file system operations between Mac and WSL2? I jumped ship from Windows to Mac before WSL2 as it was just too slow to use. Unfortunately the Mac isn't much better so I'm curious if it's worth moving back with WSL2.

runjake 5y ago
Mac FS performance was abysmal, last I checked. WSL2 FS performance is still even worse (but still tolerable).
OJFord 5y ago
What do you do that fs performance is your primary/a major concern in choosing an OS (esp. among the major ones)? I don't mean to sound snarky, I'm curious. For all I know it should matter to me more!
- andrewl-hn 5y ago
  JavaScript development tends to involve a lot of files. Between Babel, ESLint, Webpack, Post-CSS with their high number of plugins, presets, and other support modules, Typescript, testing frameworks like Jest (that comes with it's own test runner, mocking facilities, transpile-aware code coverage etc.), and general tendency for JS developers to favor composing software out of many small modules - a typical JavaScript project (browser or Node) has thousands of modules and tens of thousands of files in node_modules folder. Plus, a typical JS development process involves a filesystem-based watcher that reloads parts of an application on a fly as a developer changes code. As a result, for a very big percentage of programmers filesystem performance is crucial for their day-to-day work. There's an argument to be made that JS development ecosystem is unnecessary complex, and there are projects that try to change the status quo, but they are not ready for a prime time and aren't widespread enough yet.
  - OJFord 5y ago
    Hm I certainly sympathise, just hadn't occurred to me the filesystem might be a bottleneck here. I switched from my work Mac to my desktop and bought (or rather, so I could buy) more RAM, since it was exhausted building, and would frequently crash. I now have enough to be able to give it 'enough' and cgroup limit it from hogging more and interrupting my browsing etc. but I don't think I've given it so much that, what, the speed at which it can read the 100ks of files in order to 'webpack' them is the limiting factor. Perhaps I'm just (foolishly) content living with it much slower than you are, so I don't have everything else fast enough for that to be the problem.
AaronFriel 5y ago
Don't have a Mac but I'm on a team where I use WSL2 and my fellow engineers use Macs, which I believe consist of the 2020 i7 and i9 13" and 15" Macbook Pros, depending on engineer choice. My Dell laptop has an i7-9750H and 32GB RAM, which I think is roughly comparable. I can say that my WSL2 and Docker builds, especially when volume mounting a code directory into a Docker container, are typically much faster. I don't know if I could quantify it, but I'd rank it roughly like this: 1. Windows WSL2 (EXT4 fs) when using WSL2 directly or docker and code is in WSL2 (since Docker is just using the overlay storage driver) 2. Mac APFS directly - no Docker, just brew-based npm and "npm install" [big gap] 3. NTFS 4. APFS volume mount into container 5. WSL1 "npm install" [gap] 6. WSL2 <-> Windows filesystem bridge (files on Windows NTFS, running npm install from Linux)

runjake 5y ago

Mac FS performance was abysmal, last I checked. WSL2 FS performance is still even worse (but still tolerable).

OJFord 5y ago

What do you do that fs performance is your primary/a major concern in choosing an OS (esp. among the major ones)? I don't mean to sound snarky, I'm curious. For all I know it should matter to me more!

andrewl-hn 5y ago
JavaScript development tends to involve a lot of files. Between Babel, ESLint, Webpack, Post-CSS with their high number of plugins, presets, and other support modules, Typescript, testing frameworks like Jest (that comes with it's own test runner, mocking facilities, transpile-aware code coverage etc.), and general tendency for JS developers to favor composing software out of many small modules - a typical JavaScript project (browser or Node) has thousands of modules and tens of thousands of files in node_modules folder. Plus, a typical JS development process involves a filesystem-based watcher that reloads parts of an application on a fly as a developer changes code. As a result, for a very big percentage of programmers filesystem performance is crucial for their day-to-day work. There's an argument to be made that JS development ecosystem is unnecessary complex, and there are projects that try to change the status quo, but they are not ready for a prime time and aren't widespread enough yet.
- OJFord 5y ago
  Hm I certainly sympathise, just hadn't occurred to me the filesystem might be a bottleneck here. I switched from my work Mac to my desktop and bought (or rather, so I could buy) more RAM, since it was exhausted building, and would frequently crash. I now have enough to be able to give it 'enough' and cgroup limit it from hogging more and interrupting my browsing etc. but I don't think I've given it so much that, what, the speed at which it can read the 100ks of files in order to 'webpack' them is the limiting factor. Perhaps I'm just (foolishly) content living with it much slower than you are, so I don't have everything else fast enough for that to be the problem.

AaronFriel 5y ago

Don't have a Mac but I'm on a team where I use WSL2 and my fellow engineers use Macs, which I believe consist of the 2020 i7 and i9 13" and 15" Macbook Pros, depending on engineer choice. My Dell laptop has an i7-9750H and 32GB RAM, which I think is roughly comparable. I can say that my WSL2 and Docker builds, especially when volume mounting a code directory into a Docker container, are typically much faster. I don't know if I could quantify it, but I'd rank it roughly like this: 1. Windows WSL2 (EXT4 fs) when using WSL2 directly or docker and code is in WSL2 (since Docker is just using the overlay storage driver) 2. Mac APFS directly - no Docker, just brew-based npm and "npm install" [big gap] 3. NTFS 4. APFS volume mount into container 5. WSL1 "npm install" [gap] 6. WSL2 <-> Windows filesystem bridge (files on Windows NTFS, running npm install from Linux)