4 ms·

since the container is executed in a VM, the I/O performance is significantly worse compared to a container that is run natively. For compiled languages or f

since the container is executed in a VM, the I/O performance is significantly worse compared to a container that is run natively. For compiled languages or for any process that creates a lot of files, this impact can be significant since the overhead can be up to 100x of what you’re experiencing natively Uhhhhhhh. I don't know what VM you're using... but if the I/O in your VM is 100x slower than the host, you can fix that. It should not take a minute and a half to write a single file.

maccard 3y ago
I'm guessing OP is on Docker for Mac. This isn't so much a VM is slow, it's that file IO on docker for mac on mounted volumes is dog slow. (It's not exactly ripping fast on windows either). If you don't mount the intermediate directory, it'll be way faster. Alternatively, use OrbStack (I feel like I'm shilling this a lot recently, I'm just a happy user), and the problem goes away.
- rtpg 3y ago
  And for everyone who has these problems and aren't, like, people who need access to Photoshop, it's "native performance" on Linux cuz there's no VM layer. It could be that the VSCode remote container stuff also gets around this problem somewhat by working "in container", effectively opting out of the Mac->Docker FS stack issues (especially with file watching....). The fact that we have an enumerable number of tools that write files and somehow ended up with a bunch of stuff built on file watching instead of signaling to a build daemon on file save/checkout is... It feels cleaner but in practice is a mess of downstream problems.
p_l 3y ago
Sounds like a case of "Running Docker Desktop on a Mac and editing file on filesystem mounted from host".
- znpy 3y ago
  More like: writing to an overlay filesystem mounted on top of several more overlay filesystem running in a linux virtual machine started by docker desktop on a mac.
  - p_l 3y ago
    Having dealt with run times changing by order of magnitude by removing the mac from equation, it will do so even if there's no overlayfs on the linux VM side. Corporate insistence on providing ill-fitting developer hardware (Macs) to what our software was being developed on (Linux, and in fact only runnable there) is why they might have paid the cost of few more laptops just for my single EC2 used to have reasonable compile times. And I wasn't even using the host filesystem for any of the busy path - it was just compile definitions and storage for built tarballs and images (if it had to schlep actual source files and temporary files over, I might have had to wait a week for a single build to finish...)

maccard 3y ago

I'm guessing OP is on Docker for Mac. This isn't so much a VM is slow, it's that file IO on docker for mac on mounted volumes is dog slow. (It's not exactly ripping fast on windows either). If you don't mount the intermediate directory, it'll be way faster. Alternatively, use OrbStack (I feel like I'm shilling this a lot recently, I'm just a happy user), and the problem goes away.

rtpg 3y ago
And for everyone who has these problems and aren't, like, people who need access to Photoshop, it's "native performance" on Linux cuz there's no VM layer. It could be that the VSCode remote container stuff also gets around this problem somewhat by working "in container", effectively opting out of the Mac->Docker FS stack issues (especially with file watching....). The fact that we have an enumerable number of tools that write files and somehow ended up with a bunch of stuff built on file watching instead of signaling to a build daemon on file save/checkout is... It feels cleaner but in practice is a mess of downstream problems.

p_l 3y ago

Sounds like a case of "Running Docker Desktop on a Mac and editing file on filesystem mounted from host".

znpy 3y ago
More like: writing to an overlay filesystem mounted on top of several more overlay filesystem running in a linux virtual machine started by docker desktop on a mac.
- p_l 3y ago
  Having dealt with run times changing by order of magnitude by removing the mac from equation, it will do so even if there's no overlayfs on the linux VM side. Corporate insistence on providing ill-fitting developer hardware (Macs) to what our software was being developed on (Linux, and in fact only runnable there) is why they might have paid the cost of few more laptops just for my single EC2 used to have reasonable compile times. And I wasn't even using the host filesystem for any of the busy path - it was just compile definitions and storage for built tarballs and images (if it had to schlep actual source files and temporary files over, I might have had to wait a week for a single build to finish...)