<FromGitter>
<paulcsmith> Where would I put that. I'm not sure I understand. In the Dockerfile somewhere?
<FromGitter>
<paulcsmith> Tried in `bash` for now and got `/usr/bin/ld: cannot find -lgc (this usually means you need to install the development package for libgc) ⏎ collect2: error: ld returned 1 exit status ⏎ Error: execution of command failed with code: 1: `cc "${@}" -o '/root/.cache/crystal/data-lib-teeplate-src-lib-file_tree-macros-directory.cr/macro_run' -rdynamic -lpcre -lgc -lpthread
<FromGitter>
... /usr/share/crystal/src/ext/libcrystal.a -levent -lrt -ldl -L/usr/lib -L/usr/local/lib` so I guess I need to install some more packages first :)
<FromGitter>
<paulcsmith> Installed libgc-dev and tried it out. Same times. ~8s in Docker (on second and third build) and ~4s outside Docker
<FromGitter>
<j8r> Thanks @paulcsmith , so this isn't linked to the script wrapper - this would be strange anyway
<FromGitter>
<paulcsmith> Yeah I think there is nothing I can do but wait for Docker to improve. There are lots of known issues with Disk IO which I am guessing is causing the slowdown. I tried using the most performant type of mount (delegated) but it only made a minor improvement
<FromGitter>
<paulcsmith> And using rsync and unison is a bit too complex to tackler for me right now. I'll just deal with the slowish compile times for now :P
<FromGitter>
<paulcsmith> Though I'm not sure what Crystal is doing with the disk that may be causing this. Maybe cache lookup/writes?
<z64>
@paulcsmith you could try not using host volumes, persist the container, and `docker cp` updated files into it instead
<z64>
i think it should be better if you keep everything in the container that way and dont have to step outside to the host
<FromGitter>
<paulcsmith> @z64 I'm not sure I understand. I need to have the hose files copied over for local development so when I make a change the watcher can recompile the app.
<FromGitter>
<paulcsmith> But maybe I just don't understand. I've also tried to use volumes for shards, node_modules, but performance is roughly the same (though it did help `yarn install` a lot to make node-modules a volume)
<FromGitter>
<paulcsmith> I wish I could figure out if the Crystal compile times are because of disk io, and if so, what folder(s) it is looking at that are causing the slowdown
<z64>
yeah thats fine. you workflow would be to update your local files, and then `docker cp` all the files into the running container, which should functionally be the same as the volume, just not "automatic"
<FromGitter>
<paulcsmith> Ohh I see. Hmm I'll have to try that. Though I'm not sure that will affect compile times. I'm not sure what is causing the slowdown. I'll try `docker cp` with no bind mounted volumes and see if it makes a difference
<z64>
that way all the files are right on the virtual disk instead of having to pass through to the host
<FromGitter>
<paulcsmith> Maybe the slowdown is just from requiring all the files in lib and src 🤷♂️ in which case what you're saying would definitely help
<z64>
@paulcsmith oh, worth mentioning in case you didn't know, you could check out passing `--stats` to the compiler. it prints the compiler stages, time spent, and memory used