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.

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.

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/

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".

> 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.

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.

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.

macOS has not abandoned its Unix layer, and in fact is still a certified Unix (https://www.opengroup.org/openbrand/register/). However, there is a growing gap between certified Unix and the innovations that *nix-like systems have included in the past decade. macOS has not kept up with Linux and the BSDs in terms of feature parity, resulting in a growing gap between the features that come with modern Linux, FreeBSD, and OpenBSD versus macOS. A minor issue is macOS's BSD-derived utilities being based on late 1990s-early 2000s versions and thus not taking advantage of functionality added in later versions of these BSDs. Other issues include no support for file systems such as ZFS and btrfs in macOS (though I remember when ZFS support was proposed for Mac OS X Leopard), and macOS not supporting FreeBSD jails (https://docs.freebsd.org/en/books/handbook/jails/).

> Other issues include no support for file systems such as ZFS and btrfs in macOS

It's no thanks to Apple, but there actually is a very good ZFS driver for macOS. I've been using it for several years. https://openzfsonosx.org/

(You can't use ZFS as your root filesystem though, which may be what you meant.)