I did some quick research. I knew Rust ABI was unstable, but I didn't realize you could create Rust ABI dynlib and Rust would automatically dynamically link it. For intra-app it would work just fine. Neat. Link: https://stackoverflow.com/questions/75903098/dynamic-linking...
However, I don't see what advantage this gives. You are going to specify that dependency in your Cargo.toml just like any statically linked crate. Anything that would invalidate the cache for a static crate would invalidate it for a dynamic linked crate. Iow, it seems like separate crates are the magic here, not the linking type. What am I missing?
Thanks for the build stats. Those are helpful. I have an M1 Max currently.
UPDATE: Good points below. As a dynlib it would create a boundary for sure (no LTO, etc.). Worth playing with, thx.
> I don't see what advantage this gives
I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.
See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones.
There are few strategies for dealing with this:
1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best?
2. Is dynamic linking as above. This seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.
3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.