Make the tauri build command faster.

[WilliamVenner]

Is your feature request related to a problem? Please describe.
Build times are very long for Tauri apps.

My computer takes about 5 minutes to build my application. It doesn't sound like much, but when you're doing little changes or need to frequently build+test stuff in release mode, it can be very frustrating. Additionally, I have a very powerful system, so that build time is most likely much worse for more limited hardware.

Describe the solution you'd like
A --quick option for cargo tauri build that produces a release-built binary in the quickest time possible, sacrificing performance or convenience.

Describe alternatives you've considered
N/A

Additional context
I find myself wanting to test stuff such as build scripts, bundles and bugs in release mode frequently. However, I have to wait 5 minutes for my application to build in release mode, even with as many compilation speed optimizations in my Cargo.toml.

It would be great if whatever is slowing the build process down can be turned off using a command line option for cargo tauri build for quick testing.

[nothingismagick]

Once beta is no longer RC, then we should start investigating benchmarking on different systems. I am moving this issue to discussions so we can track it.

[chippers]

We have a lot of dependencies, so a large chunk of the build time is spent inside the linker. This is also a problem for other large projects with lots of dependencies.

There are currently a lot of dependencies because:

1. Large important dependencies (like webkit2gtk on linux, and other ones for their respective OS).
2. We expose a large amount of functionality from Tauri and it's API.
   • I hope to reduce the number of required dependencies related this in the future.

To start out right away improving build times, try using the LLD linker built into cargo. It works on Linux and Windows but I'm unsure of macOS support. It is much faster at linking.

• Running it by setting the environmental vars manually: RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo run (or with --release).
• Setting it as a project-wide cargo config. .cargo/config.toml

  • [build]
    rustflags = ["-C", "link-arg=-fuse-ld=lld"]

See #1430 (comment) for a extremely simple wall-clock measurement where using LLD dropped my clean build time from ~24.1s to ~8s and dirty builds from ~14.8s to ~3.7s. Clean as in my application was never built, but the dependencies already were.

[WilliamVenner]

I'm already using the LLD linker unfortunately :[

[nklayman]

If you use the -d -b none arguments, it will build in debug mode and won't create any installers. This takes under three seconds on an incremental build for me.

[Kleptine]

Where exactly do you specify this command? It doesn't seem to function with either JS or Rust CLI.

[nklayman]

The arguments are now -d -b none. Edited comment to reflect that.

[ghost]

What are this arguments for? I'm trying with pnpm tauri dev -d -b none but it doesn't work.

[FabianLars]

These args have no effect on tauri dev, only tauri build

[frnco]

In Arch Linux under XMonad takes from 30 seconds to over a minute to start app in dev mode. I am a big fan of the whole idea about doing the heavy lifting when compiling so we can release a leaner, optimized version, what actually concerns me is the disruption in the development workflow caused by such waits. I love the idea of learning languages (Using XMonad probably says ore than enough about that), and I'm used to REPLs, web development etc., so the 30+ seconds wait is something that really worries me.

Tauri is still quite young, and actually considering its age it's ridiculously amazing, it's wel-rounded, it's performance is great, I still haven't had any situations where Tauri made it impossible or even unreasonably hard to do whatever I thought of, even what little tests I did on the updater thing went ridiculously well, so I'm pretty optimistic about how the project will grow, but if the startup time of the dev build grows with the project I fear it will become something like C, in that we know it's fast and awesome and that it's perfect to having the performance we desire, but working with it is not pleasing. I don't care much about release builds, I think those should be automated anyways, and if developers release from their machines and do it frequently enough that it becomes a problem, then there are bigger problems than the build time. Loading it to test what's being developed, on the other hand, impacts any developer's workflow directly, and significantly. That would be my first priority.

Being clear, I've tried Rust before and the two main reasons I never got into it was the time and disk space it needed to let me do even the most seemingly trivial things, so I realize Tauri is not to blame, but for Tauri to reach its full potential I believe this situation should be improved to some extent. Either that or Google gets behind it and throws money at the problem, worked for Android, even though developing for Android is a ridiculously unreasonable pain... Anyways, to me this disruption in the workflow is the biggest issue Tauri currently has, and mitigating that seems to be the biggest issue with the current version.

[piotrpdev]

Hi, does anyone have an update on how fast the build command is now? I'm deciding between tauri and wails, and fast compile times are one of the big reasons I'm thinking about using wails.

[bling-yshs]

About 3 minutes

[piotrpdev]

About 3 minutes

Thank you 🙏

[theaddonn]

And that was 2 Weeks ago

[yashasnadigsyn]

It is nearly 1-1.5 minutes for me using fedora. Sometimes it takes up to 3 minutes.