[johncarmack1984]

Closes #16399

config::parse::parse_json isn't generic, so every build of tauri-utils generates code for it and for the Config deserializer it calls. Nothing in Tauri calls it: tauri-build, tauri-codegen and tauri-cli read the config as a serde_json::Value and convert it themselves. With #[inline], rustc only generates that code in a crate that calls the function. parse_json5 gets the same attribute. Signatures and behavior don't change.

Rebuilding just tauri-utils on dev and on this branch (M2 Max, median of 8 interleaved runs, CPU time):

tauri-utils copy	profile	dev	this PR
app (compression,resources)	dev	5.14 s	4.21 s (-18%)
app (compression,resources)	release	7.03 s	5.19 s (-26%)
build scripts and macros (build-2,compression,resources)	dev	8.79 s	8.35 s (-5%)

The dev rows touch crates/tauri-utils/src/lib.rs and run cargo build -p tauri-utils --lib --features <features> with CARGO_INCREMENTAL=0. The release row is cargo rustc -p tauri-utils --lib --release with the workspace's release profile, which Cargo builds with -C linker-plugin-lto, the same flags an app's copy gets under LTO. This branch was lower in all 8 runs for both app rows and in 7 of 8 for the build scripts. It's CPU on cold builds: incremental builds of an app don't recompile tauri-utils.

cargo fmt, the workspace clippy, the tauri-utils tests on 1.90 with all features and with none, and cargo check of tauri, tauri-build, tauri-codegen, tauri-macros and tauri-cli pass.

[Legend-Master]

I can't seem to find any meaningful differences between runs on a minimal app, could you share a bit more on how you benchmarked the results?

[github-actions]

Package Changes Through 609ddc5

There are 7 changes which include @tauri-apps/api with patch, tauri-bundler with patch, tauri-cli with patch, @tauri-apps/cli with patch, tauri with patch, tauri-runtime-wry with patch, tauri-utils with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.12.4	2.12.5
tauri-utils	2.10.2	2.10.3
tauri-bundler	2.10.4	2.10.5
tauri-runtime	2.12.2	2.12.3
tauri-runtime-wry	2.12.3	2.12.4
tauri-codegen	2.7.4	2.7.5
tauri-macros	2.7.4	2.7.5
tauri-plugin	2.7.2	2.7.3
tauri-build	2.7.4	2.7.5
tauri	2.12.5	2.12.6
@tauri-apps/cli	2.12.4	2.12.5
tauri-cli	2.12.4	2.12.5

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[johncarmack1984]

Those numbers are CPU time for rebuilding tauri-utils on its own, not a whole app: touch crates/tauri-utils/src/lib.rs, then CARGO_INCREMENTAL=0 cargo build -p tauri-utils --lib --features compression,resources under time, alternating dev and this branch, 8 runs each.

The bigger gain comes with the size profile from the docs (codegen-units = 1, lto = true, opt-level = "s"), which is also this repo's release profile. With it, the app's copy goes from 7.03 to 5.19 s of CPU (-26%, against -18% in a dev build), since that profile optimizes the unused Config deserializer in one codegen unit. In a cold release build of a bare 2.12.5 app with that profile, the two tauri-utils units in --timings drop from about 6.5 and 7.7 s to 5.8 and 6.4 s, and total CPU from 195.1 to 193.3 s (lower in 4 of 4 runs). Wall time stays about 55 s, since tauri-utils compiles alongside other crates.

A dev build of the same app takes about 22 s either way, with total CPU going from 141.3 to 138.8 s. Incremental builds don't recompile tauri-utils at all.

[Legend-Master]

thanks for explaining, this seems to be safe to add even if the gain's not significant