3 ms·

We’ve been running VMs at near native speeds for a decade. Docker on Mac runs 20-50x slower mostly due to poor I/O which is a platform “feature”, they are alrea

We’ve been running VMs at near native speeds for a decade. Docker on Mac runs 20-50x slower mostly due to poor I/O which is a platform “feature”, they are already on the latest hypervisor framework provided by Apple.

favorited 5y ago
You can run VMs on the Mac at near native speeds. I play some pretty unoptimized games with friends who are running Windows in a VM on their M1 Macs, and their performance is fine. It turns out Windows developers using Docker have the same complaints that Mac users of Docker do. In fact, I know people who run Docker Desktop inside a VirtualBox Linux VM on their Macs because it's so much faster than the VM Docker spins up.
- easton 5y ago
  The problem isn’t that the VM itself is slow (in fact, Apple’s hypervisor is pretty good IME) but that sharing files with the Mac filesystem is slow. If you use Docker volumes the issue goes away, but that’s kind of hard unless your editor has support for cloning your code to a Docker volume (so, it’s hard unless you use VSCode). The dev environments feature in preview for Docker Desktop[0] is supposed to make this flow easier, but if you have to do anything that doesn’t fit into the “I’m writing a web service that is easy to proxy” mindset, you’re better off doing a full VM with Linux (via Multipass or VirtualBox or whatever) and keeping your code in there if you want maximum performance. 0: https://docs.docker.com/desktop/dev-environments/ https://docs.docker.com/desktop/dev-environments/
  - sneak 5y ago
    Reminder: Docker Desktop is a) closed source and b) also is spyware. You're much better off using your own VM and the free software docker CLI tool. Set DOCKER_HOST to "ssh://root@$VM_IP".
eyelidlessness 5y ago
> Docker on Mac runs 20-50x slower mostly due to poor I/O which is a platform “feature” Unsubstantiated claims like this often get a rise out of me, and I was tempted to reply with a sarcastic “go on…”, but I’ll try to have a more charitable discussion. APFS performs very well. So does ext4 or zfs or whatever. So it seems your claim is not only that the file system bridge is the source of performance degradation (which it is, I agree), but that’s somehow by design for [reasons]? This is my sincere, charitable attempt to understand your scare-quote laden use of the word feature. Is that what you mean? If so, can you explain why? If not, I’m happy to understand what you actually mean.
- ricardobeat 5y ago
  That might be exaggerated because I'm including overhead from other aspects of Docker, but those are not exactly made up numbers - it's roughly the difference between building the project I currently work on locally, vs building its Dockerfile. It goes from 10-20s to 6 minutes. It takes 2-3 minutes to install node_modules alone due to the massive number of files. Trying to mount them with buildkit, provide a prepackaged cache folder, etc, are all pointless since they suffer from the same I/O slowdown. Building a go executable also goes from < 10s to > 60s.
  - eyelidlessness 5y ago
    I don’t question your measurements, I even agreed with your technical root cause analysis. What I questioned was, emphasis added to clarify: ‘poor I/O which is a platform “feature”’. This seems like a chip on shoulder attack, but it doesn’t seem like you have that particular chip on your shoulder. So I’m asking again if you can clarify what you meant by platform feature.

favorited 5y ago

You can run VMs on the Mac at near native speeds. I play some pretty unoptimized games with friends who are running Windows in a VM on their M1 Macs, and their performance is fine. It turns out Windows developers using Docker have the same complaints that Mac users of Docker do. In fact, I know people who run Docker Desktop inside a VirtualBox Linux VM on their Macs because it's so much faster than the VM Docker spins up.

easton 5y ago
The problem isn’t that the VM itself is slow (in fact, Apple’s hypervisor is pretty good IME) but that sharing files with the Mac filesystem is slow. If you use Docker volumes the issue goes away, but that’s kind of hard unless your editor has support for cloning your code to a Docker volume (so, it’s hard unless you use VSCode). The dev environments feature in preview for Docker Desktop[0] is supposed to make this flow easier, but if you have to do anything that doesn’t fit into the “I’m writing a web service that is easy to proxy” mindset, you’re better off doing a full VM with Linux (via Multipass or VirtualBox or whatever) and keeping your code in there if you want maximum performance. 0: https://docs.docker.com/desktop/dev-environments/ https://docs.docker.com/desktop/dev-environments/
- sneak 5y ago
  Reminder: Docker Desktop is a) closed source and b) also is spyware. You're much better off using your own VM and the free software docker CLI tool. Set DOCKER_HOST to "ssh://root@$VM_IP".

eyelidlessness 5y ago

> Docker on Mac runs 20-50x slower mostly due to poor I/O which is a platform “feature” Unsubstantiated claims like this often get a rise out of me, and I was tempted to reply with a sarcastic “go on…”, but I’ll try to have a more charitable discussion. APFS performs very well. So does ext4 or zfs or whatever. So it seems your claim is not only that the file system bridge is the source of performance degradation (which it is, I agree), but that’s somehow by design for [reasons]? This is my sincere, charitable attempt to understand your scare-quote laden use of the word feature. Is that what you mean? If so, can you explain why? If not, I’m happy to understand what you actually mean.

ricardobeat 5y ago
That might be exaggerated because I'm including overhead from other aspects of Docker, but those are not exactly made up numbers - it's roughly the difference between building the project I currently work on locally, vs building its Dockerfile. It goes from 10-20s to 6 minutes. It takes 2-3 minutes to install node_modules alone due to the massive number of files. Trying to mount them with buildkit, provide a prepackaged cache folder, etc, are all pointless since they suffer from the same I/O slowdown. Building a go executable also goes from < 10s to > 60s.
- eyelidlessness 5y ago
  I don’t question your measurements, I even agreed with your technical root cause analysis. What I questioned was, emphasis added to clarify: ‘poor I/O which is a platform “feature”’. This seems like a chip on shoulder attack, but it doesn’t seem like you have that particular chip on your shoulder. So I’m asking again if you can clarify what you meant by platform feature.