should basically persist on the container, however the issue that pointed out that you miss IDE functionality is definitely valid. performance (outright speed), but it's a tightrope.Īrtifacts and caching directories like var/cache, generated, node_modules, vendor, etc.
Most places I know are still using NFS, with polling, and trying to tune the fsattr cache times to get a reasonable balance of developer experience (speed of code reloading) vs. None of the existing methods account for this very well, even the relatively new mount options to try and performance boost either reads or writes don't particularly help because of the relative symmetry under certain configurations.
I hope leaving a note here is not unwelcome to highlight a particular difficulty in booting Rails applications in Docker on macOS.īetween Rails hot code reloading, which has a semi-hard dependency on working filesystem events (the polling alternative can eat as much as 20% of system CPU) and Bootsnap, which is a caching loader which tries to speed up booting Rails by bypassing the parsing step (and caching compiled btyecode on disk) which means that booting a Rails app with bootsnap loaded writes as many file as it reads (sometimes), but other times (e,g warm start) has a very different read/write ratio.
0 kommentar(er)
