Large Binary Size for Release Builds (>20MB under Linux)

[jsprog]

For the minimal project below, I could confirm that the cargo build --release binary size is no less than 20MB under Linux-x64

# Cargo.toml

[package]
name = "freya-intro"
version = "0.1.0"
edition = "2021"

[dependencies]
dioxus = { version = "0.5.1", default-features = false, features = ["hooks", "macro"] }
freya = { version = "0.2.2" }

[profile.release]
lto = true
strip = true
panic = 'abort'
opt-level = "z"
codegen-units = 1
debug = false
incremental = false 

// src/main.rs

use freya::prelude::*;

fn main() {
    launch(|| rsx!(
        label { "Minimal Example" }
    ));
}

After inspecting the output file, I could confirm that .rodata section is taking up the largest amount of the file size followed by the .text section

objdump target/release/freya-intro --headers --section .text

target/release/freya-intro:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
 14 .text         008731e0  0000000000d1fec0  0000000000d1fec0  00d1eec0  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

objdump target/release/freya-intro --headers --section .rodata

target/release/freya-intro:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
 10 .rodata       00b1ee00  00000000000a9000  00000000000a9000  000a9000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

Followed by that, I used upx to reduce the final binary size even further
upx --best --overlay=strip -o target/release/freya-intro-compressed target/release/freya-intro

                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.4       Markus Oberhumer, Laszlo Molnar & John Reiser    May 9th 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  23003384 ->   9056916   39.37%   linux/amd64   freya-intro-compressed        

Packed 1 file.

Unfortunately, It's having a negative side effect on RAM usage (already doubling)

After that, I had to objdump content for both .text and .rodata sections for further inspection

mkdir dump
objdump target/release/freya-intro -s --section .text > dump/.text.txt
objdump target/release/freya-intro -s --section .rodata > dump/.rodata.txt

And I could confirm that .rodata is containing several occurrences of useless textual data which should be useful when debugging due to some absolute paths referencing the development machine (e.g: /home/username/.cargo/registry/src/index.crates.io-.......)

I conclude that some unnecessary content related to development is getting linked into the .rodata section of the release build, and discarding it may help reduce both the final binary size and even ram usage.

I understand that content inside .rodata section should be discarded before the link step. probably some inner libraries are keeping this content regardless of release build optimizations.

Question: How to get rid of the extra content and reduce the final binary size even further by a large margin?

[marc2332]

Hey, last time I checked most of the size came from Skia, which I don't think I can do much about it.

probably some inner libraries are keeping this content regardless of release build optimizations.

Is it possible to know what libraries?

Question: How to get rid of the extra content and reduce the final binary size even further by a large margin?

You could try bundling your app using cargo-packager for example, afaik it compresses app in the installer and then uncompresses it upon install.

[jsprog]

@marc2332, slint has the support of the optional i-slint-renderer-skia that depends on skia-safe. I already confirmed the generated executable is less than 15MB

Linux: 14MB
Windows: 12.2MB

[marc2332]

Optional in what way? What exactly is optional?

[jsprog]

Slint has the support for different backends and renderers https://docs.slint.dev/latest/docs/slint/guide/backends-and-renderers/backend_winit/. For the screenshots above, I already enabled renderer-skia flag feature to improve text rendering and the executable bloated beyond 10MB

[suoyukii]

It is suggested to have two versions of Freya coexist: one using the current Skia, and the other using Tiny-Skia.

Maintaining two separate versions with different Skia renderers makes the code much easier to maintain.

[marc2332]

I will not use tiny skia