Closed Andrew15-5 closed 1 week ago
Dioxus doesn't read or modify your Cargo.toml
. It uses cargo to build your project with the settings in your Cargo.toml
.
Do you see a change in binary size when building with cargo directly?
I didn't try the cargo-direct method, only with/without env var and config changes.
Hmm, the data is kinda confusing:
dx build -r
7272640 ./dist/desktw symbols
7268544 ./dist/desktw debuginfo
12352256 ./dist/desktw none
7268544 ./dist/desktw (unset)
RUSTFLAGS='-C strip=?' dx build -r
7110600 ./dist/desktw symbols
8787672 ./dist/desktw debuginfo
11992856 ./dist/desktw none
cargo build -r
7035072 ./target/release/desktw symbols
7035072 ./target/release/desktw debuginfo
12065536 ./target/release/desktw none
7035072 ./target/release/desktw (unset)
RUSTFLAGS='-C strip=?' cargo build -r
6877128 ./target/release/desktw symbols
8503272 ./target/release/desktw debuginfo
11708832 ./target/release/desktw none
The one thing that stands out is the dx build -r
makes smaller binary when symbols are left inside vs. everything is stripped. And for some reason, dx
makes binaries bigger than cargo
.
We use option_env!()
to import some configuration by for desktop apps if you build with the CLI so that desktop settings like the window name are copied from the dioxus.toml
. I would expect the binary size to be slightly larger when you build with the CLI because of that.
The difference between strip and no strip in dioxus and cargo seems pretty similar (-162040 in dx) (-157944 in cargo) so this doesn't seem like a bug in dioxus.
If you would like to minimize the size of your release binary, there are several other settings you can add to your .cargo/config.toml
described in the optimization section of the reference:
[unstable]
build-std = ["std", "panic_abort", "core", "alloc"]
build-std-features = ["panic_immediate_abort"]
[build]
rustflags = [
"-Clto",
"-Zvirtual-function-elimination",
"-Zlocation-detail=none"
]
# Same as in the Stable section
[profile.release]
opt-level = "z"
debug = false
lto = true
codegen-units = 1
panic = "abort"
strip = true
incremental = false
When building with nightly and those settings, the tailwind desktop bundle goes from ~5mb to ~2mb for a macOS ARM
Closing this issue as not reproducable
We use
option_env!()
to import some configuration by for desktop apps if you build with the CLI so that desktop settings like the window name are copied from thedioxus.toml
. I would expect the binary size to be slightly larger when you build with the CLI because of that.
Is this code inserted in the resulting binary? Or is this code from the dx
? Because including short strings shouldn't make such a noticeable difference in size.
So, if I don't set any names programmatically, then the only difference between two building methods is just a few embedded strings? Like, is it typically safe to use cargo instead of dx to build things?
Is this code inserted in the resulting binary? Or is this code from the dx? Because including short strings shouldn't make such a noticeable difference in size.
The JSON string is compiled into the binary. It could also trigger more code in dioxus desktop to get included into the final binary because the settings in the dioxus.toml are applied
So, if I don't set any names programmatically, then the only difference between two building methods is just a few embedded strings? Like, is it typically safe to use cargo instead of dx to build things?
Yes, you can typically use cargo instead of dx if you want to. Just keep in mind, not all of the settings in your Dioxus.toml
will be applied to your build and assets with manganis
will not be optimized/copied
I was able to reduce file size from 6.6 MiB to 2.9 MiB! Though this is great, the unfortunate part is that the full startup time has not been decreased. It still says at about 1.1 s (versus 0.8 s for the default Desktop + TailwindCSS project).
Yes, you can typically use cargo instead of dx if you want to. Just keep in mind, not all of the settings in your
Dioxus.toml
will be applied to your build and assets withmanganis
will not be optimized/copied
So you probably can add a build.rs
script for this instead, right? Then mimic all or most of the dx
's behavior in there, and it will be about identical, but "the big selling point" is that you or someone else doesn't have to have a dx
around, just the Rust toolchain.
So you probably can add a
build.rs
script for this instead, right? Then mimic all or most of thedx
's behavior in there, and it will be about identical, but "the big selling point" is that you or someone else doesn't have to have adx
around, just the Rust toolchain.
Yes, we have tried to include different parts of the CLI like hot reloading and asset compression in the application or a macro before, but it ends up performing poorly because macros and build scripts run in debug mode and don't persist between recompiles
Hmm, ok, good to know. Thanks!
Problem
strip
setting for release profile doesn't change the binary's file size, even though I checked the docs (and this) and it should change the binary even if by a few bytes. But it doesn't work. Or maybe normally doesn't work (I think once it did change something, but maybe not). It only works viaRUSTFLAGS='-C strip=symbols'
.Steps To Reproduce
Steps to reproduce the behavior:
create a project with
dx new
(Desktop+Tailwind)cd project_name
add this to the
Cargo.toml
:run
dx build -r
see the binary size (
du -b ./dist/binary_name
)change the
strip
's value as the binary's size shouldn't changeprepending
RUSTFLAGS='-C strip=symbols'
will apply the correctstrip
levelExpected behavior
strip
setting for release profile should change binary's file size.Environment:
Questionnaire