[feat] Support the dynamic linking of the tauri crate for much faster incremental compile times

[horvbalint]

Describe the problem

Incremental compilation times on my machine take about 11 seconds. Waiting this much even for the smallest changes in the rust code is quite inconvinient.

Describe the solution you'd like

Simply making the 'tauri' crate a 'dylib' almost halves this wating time (takes less then 6s).
This should be only enabled in development builds as in production it would require that the genrated 'libtauri.so' file is also shipped with the binary.

The problem is that cargo currently doesn't support a conditional 'crate_type' based on profiles (at least as far as I know it). So one must use a workaround for this. bevy provides a cargo feature called 'dynamic', which forces the crate to be compiled with dymanic linking.

Here are the threads where they discussed the possibilities and the solution:
bevyengine/bevy#791
bevyengine/bevy#808

To test the impact this has on compile times simply add

[lib]
crate_type = ["dylib"] 

to the 'core/tauri' crate's Cargo.toml file and run your app with 'cargo run' inside the 'src-tauri' folder.
The command tauri dev will fail as it doesn't find the 'libtauri.so' file for some reason. I couldn't figure out where it is looking for it.

Alternatives considered

As mentioned in the bevy issue, it is also possible to set 'crate_type' to ["rlib", "dylib"] and then set the env var RUSTFLAGS=-Cprefer-dynamic when running cargo run.

One of the problems mentioned with this in the bevy issue is, that it has to be set by the developer manually. I think this might not be a problem in tauri since we use tauri dev to run the project wich could set this env var for us automatically.
There is an other problem mentioned for this approach, which is beyond my knowledge: "this doesnt play nicely with rust-analyzer by default because RA invalidates the build cache. this is probably fix-able by configuring RA to also use -Cprefer-dynamic"

Additional context

I am not an experienced Rust developer, and I am new to tauri as well. Sorry if some of the things I wrote above are incorrect.

[horvbalint]

There is a recent blog post explaining this method far better then I could. I still think that it would worth to implement this in Tauri: https://robert.kra.hn/posts/2022-09-09-speeding-up-incremental-rust-compilation-with-dylibs/

[granitrocky]

I was thinking about this a lot, so I made my own fork to try it out.

https://github.com/granitrocky/tauri/tree/dynamic_linking

Feel free to give it a whirl. It should be plug and play with an existing tauri project (minus updating the paths in your Cargo.toml to point to the local version).

You should be able to add the ["dynamic"] feature to tauri and see a measurable increase in compile speed. The bad news is that it didn't drop it all the way down to sub 1s like it does for bevy for me.

But it does cut the compile time in half for me from 8s to 4s on my mid range laptop, which is a nice boost when making lots of small changes.

Other speedup options are to try other linkers like lld and mold. I haven't experimented with that yet, but I imagine the linker isn't the weak link after switching to a dynamic library.

If you think this is useful, I may open a PR to get a conversation going with the maintainers

[JonasKruckenberg]

The approach used in your fork obviously wouldn't be accepted as a PR as-is (renaming the main crate breaks almost everything in existence) but I personally like the idea. Maybe some more research is needed to make the API feel good though

[granitrocky]

The bevy approach was to create bevy_internal, and move all the major stuff in there, but I understand that Tauri has a lot of FFI stuff that could topple.

And yeah using the tauri main crate in place of core/tauri could be really messy.

I'll see if I can come up with something better.

[horvbalint]

@granitrocky After I opened this issue and failed to implement what you did (congrats!) I tried what a change mold would do to a tauri app and my mind was blown. Incremental compilation time went down from 8s to 1.4s 🤯
Still I do think this issue of dynamic linking would be beneficial to get into Tauri main, since mold is not available for everyone (like any Windows user).

[thewh1teagle]

Really looking for this. incremental compile takes 10s with fresh tauri v2 app on Windows. (Even on macOS m1 is not that fast..)

See how bevy crate does that:
https://bevyengine.org/learn/quick-start/getting-started/setup/#dynamic-linking

hyperium/hyper#2770