7 ms·
If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine. That means that whenever you call Docker
by toxik 5y ago
If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine.
That means that whenever you call Docker, it has to copy your "context" to the virtual machine, then actually run the Docker invocation inside the VM. This gets slow and annoying very fast for even 10MB "contexts".
"Context" is anything in your working directory, more or less.
- udp 5y agoFreeBSD once had Docker working through the Linux compatibility layer. No virtualisation. I always thought would have been really cool to see that ported to macOS.
- Stranger43 5y agoThat depends a lot on weather the freeBSD compatiblity layer is kernel or user space as MacOS contrary to common space does not use an freeBSD derived kernel but one derived from the CMU mach64 project, and yes i know jobs said otherwise but he was never a trustworthy source for anything. I think macos actually uses an different binary executable format then the elf64 one shared between linux and freebsd, so the kind of binary level compatiblity that linux and freebsd share might not be shared between macos and freebsd.
- sa46 5y agoAnother common slow down is bind mounts. Each file system operation is an RPC request between Docker for Mac and the Linux VM. I’ve never been super happy with Docker for Mac. I did a pretty deep dive into figuring out why it’s so slow with no satisfying conclusion: https://stackoverflow.com/q/58277794/30900 https://stackoverflow.com/q/58277794/30900
- fart32 5y agoThis is also true for Windows. WSL2 made containers faster, but FS is painfully slow. Sounds like the best thing (apart from switching) is running Linux in a VM (Hyper-V does OK) and having IDE, Docker and all the data in there.
- nickjj 5y ago> WSL2 made containers faster, but FS is painfully slow. If you keep your code base in WSL 2's file system it's really really fast. Even thousands of tiny asset files will get picked up and compiled through multiple Webpack loaders in ~100ms on 5+ year old hardware.
- fart32 5y agoWhat I really had an issue with was the timespan between modifying a file in an editor (running in Windows) and the change being actually present in the container. I had to restart tests way too often because the old code was executing, which was really annonying, as sometimes you can't really tell if it failed because of the old code, or because the implementation was wrong. The problem here is the delay between Windows and WSL2, once the files are in WSL2, it's fine. I may give it another chance, though. Thank you.
- lugged 5y agoThis is trivially worked around with volume mounts and properly configuring VM / container resources. The overhead should be incredibly minimal. It is a waste of time though. Just use Linux.
- oblio 5y agoI don't think they can really use Linux on Apple hardware. At least not as professional developers that don't want to fight the hardware, the OS <<and>> their development project.
- lugged 5y agoSo get a ThinkPad? Or a surface pro, or a Dell, or a Chromebook, or a system76?
- oblio 5y agoI guess you missed the latest news about those devices with 20 hour battery life and the performance of a Intel device weighing twice as much :-)
- contriban 5y agoI doubt anyone would need to work anywhere near 20 hours without being connected at all. The vast majority of people work on desks with plugs.
- 5y ago
- nly 5y ago> If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine. True of Windows too.
- hibbelig 5y agoAnother problem is that bind mounts are slow; we put data into volumes if it's accessed often.