Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
horvbalint opened this issue Aug 7, 2022 · 5 comments

Comments

@horvbalint
Copy link

horvbalint commented Aug 7, 2022

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

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
Copy link

granitrocky commented Jan 18, 2023

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
Copy link
Author

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 📬Proposal
Development

No branches or pull requests

3 participants