Our approach is to focus on functionality and correctness first, and then improve performance over time.
We're building up a suite of performance benchmarks to help us track progress-- are there particular benchmarks that you would recommend we add? I'll certainly add "CPU load while idling" to the list.
Maybe something like a Django, Rails, etc. DEBUG=True dev server - they tend to poll for file changes which could really tax your osxfs implementation at "idle".
> Our approach is to focus on functionality and correctness first, and then improve performance over time.
Just my two cents: I think that the interface and features are excellent and a joy to use, but performance was a show-stopper that forced me to quit using the Beta for Rails-application development:
- a simple request that took ~1/3 of a second using VirtualBox and Docker Machine took six seconds on Docker for Mac
- a more complex request went from one second to twelve seconds
I didn't have a chance to dig into it, but I would guess that it has something to do w/ osxfs and the many files that Rails loads, as it reminded me of the difference between using sharing files via VirtualBox's own file sharing vs. NFS, the latter being a significant improvement.
I've noticed this as well. It seems like the docker.local hostname can sometimes take a long time to resolve. If I resolve that hostname and visit the IP directly it generally works great.
Definitely check out the beta forums as most of the issues I've found have already been reported with workarounds.
I'm wondering how Docker for Mac handles conflicting entries in /etc/exports. This is currently still a problem when using dlite and vagrant on the same host[1].
Our approach is to focus on functionality and correctness first, and then improve performance over time.
We're building up a suite of performance benchmarks to help us track progress-- are there particular benchmarks that you would recommend we add? I'll certainly add "CPU load while idling" to the list.