@kieckhafer I'm interested to know whether you see any improvement with these changes.

@aldeed Startup time is a slight improvement, but reload time after a change is a HUGE improvement. @mikemurray check this out, see how it works for you.

Initial startup time
This PR: 6m45s on average
Previously: Over 8 minutes, usually closer to 10 minutes

After making a change
This PR: 20 seconds!
Previously: 3-10 minutes, depending on how long the app has been running

One odd thing, not sure if this has to do with the caching or not. After a change, I am able to reload the page right away, which is nice, as in the past if you try that it just spins forever while the app is restarting. However, if you reload immediately, you don't see the changes. If you wait about 20 seconds to reload, then you do see the changes.

Can we make this support debugging? Maybe add these to package.json scripts?

"inspect": "node --experimental-modules --inspect ./.reaction/run/index.mjs",
"inspect-brk": "node --experimental-modules --inspect-brk ./.reaction/run/index.mjs",
"inspect-docker": "node --experimental-modules --inspect=0.0.0.0:9229 ./.reaction/run/index.mjs",
"inspect-brk-docker": "node --experimental-modules --inspect-brk=0.0.0.0:9229 ./.reaction/run/index.mjs",

I was working on getting this reaction-cli PR released but this would make that obsolete.

CC: @loan-laux Heads up FYI. This might provide an alternative way to get debugging working. I might test my proposed changes to this setup locally and see if that works.

@aldeed What do you think about these changes to support debugging

@aldeed Did you try delegated docker volume setting? My reading of the docs would indicate that would be more appropriate for us instead of cached.

However, by relinquishing consistency, delegated mounts offer significantly better performance than the other configurations. Where the data written is ephemeral or readily reproducible, such as from scratch space or build artifacts, delegated may be the right choice.

@focusaurus re: delegated, the definitions are:

• consistent: perfect consistency (host and container have an identical view of the mount at all times)
• cached: the host’s view is authoritative (permit delays before updates on the host appear in the container)
• delegated: the container’s view is authoritative (permit delays before updates on the container appear in the host)

Delegated sematics section reads:

If changes to the mount source directory are present on the host file system, those changes may be lost when the delegated mount synchronizes with the host source directory.

Doesn't that mean that developers could lose changes to thesrc directory?

Quicklink to docs: https://docs.docker.com/docker-for-mac/osxfs-caching/

I see. I thought it was just "delays" not losing changes. Do we want a delegated mount just for the .meteor directory though?

@focusaurus Got it. Would definitely be nice having debugging on here. Really excited about these perf improvements — nice job!

@kieckhafer @aldeed Here are my results. Seems to shave off 1-2 mins

Initial startup time

docker-compose down -v --rmi local
docker-compose up -d

This PR: ~5m57s
Previously: ~6m50s

Stop 'n start Reaction container

docker-compose stop reaction
docker-compose up -d reaction

This PR: ~2m42s
Previously: ~4m28s

After making a change
This PR: ~50s
Previously: ~1m41s

@ticean oops! i didn't mean to re-request a review from you. clicked that mysterious button on accident!!

@focusaurus I pulled in the debugging changes from your branch. Thanks!

cached makes the most sense to me for the project files, but I hadn't thought about .meteor. The files directly in .meteor are probably best treated as part of the project and therefore cached, but .meteor/local, where all of the temporary builds are done, seems right for delegated. I'm a bit worried about what might happen when mixing cached and delegated in the same tree like that, but I guess there's one way to find out...

Also based on my reading I think these control both whether delays are OK and which is the source of truth when updates conflict. The host is SOT for cached and the container is SOT for delegated. Otherwise in normal mode they jump through hoops to ensure there can never be a conflicting view, which is why it leads to poor performance on Mac.

Using delegated for .meteor/local seems to work for me. I'm going to get this merged, but if anyone encounters related issues once this is in develop we can discuss and fix or revert as necessary.