Live data from Hacker News

Improve Docker performance on macOS by 20x

pen.so

11–18 of 18 posts

Re: Improve Docker performance on macOS by 20x

#12

Can you retest with experimental virtualization enabled? At least on my M1 this boosted performance a LOT (in addition to using gRPC FUSE mounts, as a other commenter also posted)

I just tried on the repo links in the post, had hopes when I read your comment. But it makes no difference...

Re: Improve Docker performance on macOS by 20x

#13
post #6

it's not really an improvement if you have to run your dev environment inside a VM, with the inconvenience of not having access to the files in the host.

I use ssh and vim so it works for me, but agreed it doesn't work for everyone.

From looking over your Vagrantfile it looks like the project files are mounted from the host into the VM so ssh would only be required for tunneling to the db connection? (Although that can also be avoided by exposing a port or using bridged networking).

The biggest issue I've found with this kind of setup is that file change events from the host don't cascade to the virtual machine using VirtualBox's shared folders. NFS handles this better (still seconds delay based on cache values) but that is then a problem for Windows users.

It's been a few years since I switched to using Linux natively so my knowledge on Docker for Desktop Mac mount strategies may be out of date, but at one point docker introduced options such as :cached and :delegated which can have a considerable improvement to container file access speeds. Additionally, I've heard of people using mutagen and nfs for significant improvements, but I've never tried that setup. Here's a long discussion about it: https://github.com/docker/for-mac/issues/1592#issuecomment-6...

Re: Improve Docker performance on macOS by 20x

#14

Earlier quoted context omitted.

I use ssh and vim so it works for me, but agreed it doesn't work for everyone.

From looking over your Vagrantfile it looks like the project files are mounted from the host into the VM so ssh would only be required for tunneling to the db connection? (Although that can also be avoided by exposing a port or using bridged networking). The biggest issue I've found with this kind of setup is that file change events from the host don't cascade to the virtual machine using VirtualBox's shared folders.…

I've tried it all and the only real solution is a Linux VM without shared folders, which I'm fine with. The project I booted is used by other colleagues so I tried to make it "generic" and then yes, vagrant copies the file.

As you said (and others in comments) bidirectional syncing with docker-rsync, or using NFS, is one way to have files synchronising but it always ends up being a pain.

I did use cached and delegated but it's nowhere near close to the ideal solution: removing macOS of the equation. At least until Docker find a real fix for those performance issues, if anytime.

Re: Improve Docker performance on macOS by 20x

#16
post #9

Maybe a dumb question, but are they running M1 with the ARM version of Docker & Ruby? I imagine it’s probably difficult to accidentally get the AMD64 version, but I didn’t see that detail in the benchmark

author here. M1 was running arm images, but as far as I know Docker Desktop on M1 use Qemu which is super slow anyway.

Uh, why? All projects I saw in the early days of M1 (first some script with a modded version, then UTM) were using Qemu to demonstrate the power of Virtualization.Framework (with near native performance). What is Docker doing wrong?

Re: Improve Docker performance on macOS by 20x

#17

Can you retest with experimental virtualization enabled? At least on my M1 this boosted performance a LOT (in addition to using gRPC FUSE mounts, as a other commenter also posted)

I’m going to try this later. I noticed the slowdown switching from a relatively weak Linux server to my M1 Macbook and had already accepted the disappointment of the M1 not being so great after all.

Re: Improve Docker performance on macOS by 20x

#18
post #8

Hate its popularity at my job.. it’s fine if you want to use it for a tech stack in the background like a db or cloud emulation.. but call me old fashioned I think if you’re walking around calling yourself a software engineer, loading up software and tools is part of the job.

+1 That's not a thing at my job but I have given up using docker to replace the native dev environment. The idea of having each dev environment isolated and therefore not polluting the host system seems appealing but impractical. Performance penalty is a big issue if you are not on a Linux desktop. Docker can be handy at times for things like bootstrapping an integration test environment but I prefer having a native dev environment where I can run commands for the projects, run unit tests locally and debug easily, all of which require extra hoops to jump through if done in Docker.
Post reply on HN