Binary size on MCU

[dobrowolski-lukasz]

I'm writing a MCU application in rust. I've used slint to make a simple UI for 320x240 screen. One big problem I've noticed is that slint is using a lot of flash.

1. hello-world using embedded-graphics: DEV: 90 KiB, REL1: 24 KiB, REL2: 22 KiB
2. hello-world using slint: DEV: 261 KiB, REL1: 170 KiB, REL2: 115 KiB
3. My UI using slint: DEV: 478 KiB, REL1: 378 KiB, REL2: 242 KiB, REL3: 282KiB
4. My UI using slint(using default font size): DEV: 423 KiB, REL1: 324 KiB, REL2: 188 KiB, REL3: 228 KiB
5. My UI using slint(using default font size, removed buttons): DEV: 319 KiB, REL1: 267 KiB, REL2: 164 KiB, REL3: 188 KiB

DEV: Dependency crates are optimized for size while my crate is not optimized:

[profile.dev.package.*]
codegen-units = 1
opt-level = "z"

REL1: Optimized for speed:

[profile.release]
codegen-units = 1
debug = true
lto = true

REL2: Optimized for size:

[profile.release]
codegen-units = 1
debug = true
lto = true
opt-level = "z"

REL3: REL2 with opt-level = "s"

I've included comparison to embedded graphics to give idea of how much flash is taken to get slint running.
It comes out to ~155KiB with REL1 settings. That's quite a bit but acceptable.
The most interesting numbers are 3.REL1 and 4.REL1 and those are bad.
The UI I've made is consists of only one screen without any images. At this rate It's unlikely that the project will fit on 512K flash that I use.

What is causing such high resource usage? / Any Tips on how can I investigate that?
Are there any settings that I can change to make the binary smaller?
Are there any plans to make slint less resource hungry? If so, how much of improvement can be expected?
Is there any low hanging fruit?

[dobrowolski-lukasz]

My ui code:

import {Button} from "std-widgets.slint";

global Skin  {
    out property <length> MediumFont: 13px;
    out property <length> LargeFont: 20px;
    out property <length> HugeFont: 27px;
    out property <length> TitleFont: 10px;
    out property <color> LightBlue: #6776FF;
}

component Channel inherits VerticalLayout {
    in property <string> channel;
    in property <string> voltage_requested;
    in property <string> voltage_actual;
    in property <string> current_requested;
    in property <string> current_actual;
    in-out property <bool> enabled <=> enabled-btn.checked;
    channel-label := Text {
        text: "Channel " + channel + ":";
        font-size: Skin.MediumFont;
        font-weight: 700;
    }
    HorizontalLayout {
        VerticalLayout {
            Text {
                text: "Actual:";
                font-size: Skin.TitleFont;
            }
            Text {
                text: voltage_actual + " V";
                font-size: Skin.HugeFont;
                color: Skin.LightBlue;
            }
            Text {
                text: current_actual + " A";
                font-size: Skin.HugeFont;
                color: Skin.LightBlue;
            }
        }
        VerticalLayout {
            Text {
                text: "Requested:";
                font-size: Skin.TitleFont;
            }
            Text {
                text: voltage_requested + " V";
                font-size: Skin.LargeFont;
                color: Skin.LightBlue;
            }
            Text {
                text: current_requested + " A";
                font-size: Skin.LargeFont;
                color: Skin.LightBlue;
            }
        }
        enabled-btn := Button {
            checkable: true;
            text: self.checked ? "ON" : "OFF";
        }
    }
}

export component MainWindow inherits Window {
    width: 320px;
    height: 240px;

    VerticalLayout {
        Channel {
            channel: "A";
            voltage_requested: "42.00";
            voltage_actual: "43.00";
            current_requested: "69.00";
            current_actual: "69.00";
            enabled: true;
        }
        Channel {
            channel: "B";
            voltage_requested: "69.00";
            voltage_actual: "68.00";
            current_requested: "42.00";
            current_actual: "41.00";
            enabled: false;
        }
    }
}

Hello World code:

export component MainWindow inherits Window {
    width: 320px;
    height: 240px;

    Text {
        text:  "Hello World!";
    }
}

[tronical]

You could try to gradually re-add pieces to see what's contributing how much.

I suspect that the glyph images resulting from different text sizes are a big factor. It would also be interesting to see how much the Button contributes, and how it differs between fluent and material. It might be worth omitting it in favor of a simpler self-made one, without the bells and whistles of dark/light mode and icons.

@xgroleau might also have some experience with this.

Another thing to try is to use opt-level="s" (worked better for me than z, but YMMV)

[dobrowolski-lukasz]

I've updated the original post with data from following tests:
Removed buttons and fonts -- scenario 5
Added REL3(opt-level = "s") to scenarios 3,4 and 5.

Using only default font size saves 54 KiB a lot (I've expected more tbh)
Removing buttons saved further 57 KiB -- a lot.

I'll try setting cargo in a way that ui generated form slint would be compiled with optimized for size while rest of my app is optimized for performance. I'll let You now how it goes.

[tronical]

Good idea to use default-font-size, that's one set of glyphs less. The button weighs quite a bit.... I wonder what that's dragging in that's not needed. What style are you using?

Edit: ah, I misunderstood. So this is the cost of all pre-rendered glyphs deviating from the default size.

[dobrowolski-lukasz]

I'm not setting any style, so the default one.

[tronical]

Ok, so fluent then. Does it help to explicitly select "fluent-light" as style? That should give less bindings.

[dobrowolski-lukasz]

I've tried:
removing color from text: no difference,
removing font-weight: no difference,
Using Channel component only once: 32KiB less

[dobrowolski-lukasz]

@tronical Could You give me a hint how to set theme? I've skimmed through docs but can't seem to find any info on that. :(
Found it, It's under build logic. Saves me 5KiB (when without buttons). When used on scenario 3.REL1 saves 6 KiB.

[dobrowolski-lukasz]

I've played around with objdump a little:
3.REL1 fonts take ~60 K

$ objdump -tC $BINARY|grep 'GLYPHS' |gawk '{s+=strtonum("0x"$5)}END{print "size=" s "\ncount=" NR}'
size=62391
count=470

4.REL1 fonts take ~7K

$ objdump -tC $BINARY |grep 'GLYPHS' |gawk '{s+=strtonum("0x"$5)}END{print "size=" s "\ncount=" NR}'
size=7106
count=94

In practice GUI app will often need more than one font size but 60K is not end of the world.

[tronical]

In the generated code we don't use FnOnce AFAICS. We do however use FnOnce a few times in the context of the property system, but those shouldn't be large. The non-software renderers have bigger uses of get_or_update_cache_entry of the item cache for example, but not the software renderer. I wish there was some kind of debug info that could explain where it comes from :)

[dobrowolski-lukasz]

I've searched for rust specific tools to analyze the binary.
I've found some that are useful:
cargo-bloat -- Easier to use than objdump but didn't let me learn anything new. It tells us how much crates weights but does not tell us what pulled those symbols in.
twiggy -- Might be useful but it's meant for wasm so some features don't work and size calculations are misleading. Maybe I could learn something if I spend more time with it. It looks that this tool might be great when it matures more.
ddbug -- This one can show us what is inlined in the symbols. This will tell us what those FnOnce are for and why do those weight that much. I'm attaching dump from that command.
ddbug.txt
I've renamed my app to "my-app" so that it's not confused with embassy framework. This is from scenario 4.REL1.
I've generated this file with: ddbug target/thumbv7em-none-eabihf/release/my-app --sort size --category function.
@tronical: Can You take a look? Maybe You can deduce something useful from this data.

[tronical]

Oh, the ddbug output looks insightful. The constructors are large (expected), and the binding for the layout data for Button is the largest FnOnce AFAICS (based on the struct i_slint_core::layout::LayoutInfo return type). That's a little surprising.

You write that this is 4.REL1. IIRC Rel1 is optimised for speed, so perhaps more is inlined than necessary. How does it compare to REL2 (opt-level = "z")?

[dobrowolski-lukasz]

ddbug-REL2.txt
ddbug-diff-rel1-rel2.txt

[tronical]

That looks significantly better. For example that layout FnOnce was 2700 bytes, with REL2 it's 512. The largest FnOnce is now fn core::ops::function::FnOnce::call_once<my_app::slint_generatedMainWindow::{impl#0}::init::{closure_env#1}, (vtable::vrc::VRcMapped<i_slint_core::component::Component_vtable_mod::ComponentVTable, my_app::slint_generatedMainWindow::InnerButton_root_27>)> with 672 bytes (return type is SharedVector<f32>, that's the binding to compute layout positions, not sure if horizontal or vertical).

The inlining choices look sensible to me, at first glance. If this is the above Slint code, then the best advice I have at this point is to still see about replacing the Button from the fluent style (std-widgets.slint) with a smaller custom button - unless you need its features. For example the Button supports an icon, and the code for that costs unfortunately - even if the icon isn't used. This is a cost that's not paid per use-site but once, but still.

[xgroleau]

I do agree that slint does use quite a lot of flash, which is also a problem for us, the UI takes more than 60% of our flash which leaves not a lot for application code and bootloader.

• As previously mentioned the more font sizes you use, the higher the flash usage (proportional to the size of the font).
• LTO to fat/true does help a bit.
• If you eventually do use SVG, note that they are rendered at compilation using the size and the viewbox, so you can resize it if needed.
• Reuse component as much as possible and inject parameters to cusomize

Your code seem to already respect that so I'm not sure how you can actually optimize more on your end other than reducing the number of components.

For the different font sizes, it could be possible to make slint resize the font at runtime for a bit of runtime overhead, but that would require modification of the slint library itself.

It's not an ideal solution but you could use an external NOR flash and XIP if your MCU supports it instead of using an MCU with bigger flash.

I'm interested on what you will find on the usage and see if it's possible to optimize the flash usage of the library

[dobrowolski-lukasz]

Fonts: I think I'll redesign UI to use less font sizes. Maybe experiment using colors instead. I think 3 font sizes would be enough for my use-case. Also I can try removing most of characters for bigger ones. I only need [0-9mAVW.] for them. That would make fonts manageable. Apart from that I don't think there is much to be gained here.

I'm going to try moving UI generation to a different crate and setting opt-level = "z" there(I haven't found a way to do this in a single crate). But as we see from counting object sizes it will not be enough. Worst part is that the UI I've made is really bare-bones and I already have size issues.

Using external flash is a possible workaround. I think I'd rather go with using lvgl if it comes to that.

After looking at objects sizes I think slint itself needs to be slimmed down for it to make sense on MCUs.
Now I'm hopeing for some optimizations that would be low hanging fruit. Unfortunately I know next to nothing about graphics.

I'll try looking through dependencies that slint pulls in -- There's too much fat there too. :/

[dobrowolski-lukasz]

I'm temporarily giving up on trying to pass opt-level = "z" to just code generated from .slint file.
I don't know how to accomplish that sensibly. If You have know feel free to answer:
https://stackoverflow.com/questions/76199516/different-optimization-options-for-different-files

I've tried to make my repo into cargo workspace and separate out the ui itself but I've ran into something that looks like cargo bug.
Compilation fails on byteorder crate. Turns out that cargo adds --cfg 'feature="default"' --cfg 'feature="std"' to rustc command when I build in a workspace. I think it's this problem:
rust-lang/cargo#4463

[tronical]

From a glance at the output it seems that InnerComponent_image_30 is the consequence of the Button's support for images, i.e. the

if (root.icon.width > 0 && root.icon.height > 0): Image {
            source <=> root.icon;
            width: 24px;
        }

inside the Button.

I suspect that new() is big because it inlines init, but that's surprisingly big overall in terms of resulting binary size.

There are surely things that can be done to reduce the size of generated code. Maybe along the lines of commit 52aee8d.