Compiler optimizations #7680

badicsalex · 2025-02-20T09:19:58Z

We've been experiencing slow builds with medium-sized slint files, and the main culprit seems to be the sheer amount of code generated. I understand that rustc will do a good job optimizing that code, but we can help it a bit on the generation side. We have a few patterns which were handled relatively poorly by slint, and that's what this PR fixes.

Summary of the changes:

Return elimination has been improved so less functions will need a return_object, allowing full const resolution in a lot of cases ¹
Functions where the parameters are const and the body only accesses consts are now automatically inlined and evaluated. This usually results with them being replaced by just a literal.²
If a component is used exactly once, it is auto-inlined
If a component is conditional or repeated, it is no longer force-inlined. This almost always results in smaller code (combined with the above change), because duplicating components is worse than just having more bindings in all but the simplest cases. ³

These changes should be 99% transparent, as they shouldn't change behavior, only make the generated code smaller. Tests needed to be adjusted, because diagnostics are moved around due to the new inlining rules.

In the future I want to use the new, more powerful const propagation to eliminate the repeaters of unconditional conditional elements, but that's a different PR for sure.

¹: Functions with the pattern function f(a: float) -> string { if a>5 { return "yes" }; return "no" } needed a return object, now they don't

²: We have a lot of global pure functions that are called like Colors.get(Palette.primary) everywhere, and they caused a lot of unpropagated constants.

³: In one specific case, we had code like:

VerticalLayout {
    if (important-items.length > 0): ItemList {
        important: true;
        items: important-items;
    }
    for section[section-idx] in other-sections: ItemList {
        header: section.header;
        items: section.items;
    }
}

Wrapping the ItemLists in a Rectangle made the code compile some 30% faster (ItemList is a complicated component here), and I didn't want to do that because it hampers readability, and there are a lot of other, similar code in our codebase.

CLAassistant · 2025-02-20T09:20:09Z

All committers have signed the CLA.

badicsalex · 2025-02-20T09:44:47Z

Seems like the CI was more thorough with its test running than I was :P

I haven;t checked yet, but I assume this is caused by the remaining cases where the LLR inlining phase inlines some attributes that the item tree inliner didn't, and that causes very obvious dead code in the generated rust files. It does show how well the elimination works in general though. The main problem I saw is is_constant on properties is too strict, but that seemed like a hard to fix issue.

(e.g. the following case:

component Icon inherits Image {
    in property <length> size: Size.sz6;
    source: @image_url("whatever.png");
    width: size;
    height: size;
}

component MultipleIcons {
    HorizontalLayout {
        Icon { size: 15px; }
        Icon { size: 30px; }
    }
}

badicsalex · 2025-02-20T12:08:48Z

Unfortunately it seems like the typeloader keeps the loaded components, some of which refer to the Icons global, which kills the named_reference refcount check in remove_unused_properties

Removing that check of course caused a panic.

Any help on how to approach this would be appreciated.

They don't need to be inlined, and a lot of the times inlining them incur a significant overhead (e.g. in case of conditional complex components)

badicsalex · 2025-02-20T12:28:12Z

Nevermind, find an issue where I didn't simplify conditional expressions enough.

The deeper issue (LLR discarding properties that previous passes don't) will remain though.

ogoffart

Thanks a lot for these changes!
Overall looking very good.
I just added a few comments inline.

Do you have any numbers on how good it improves the source code size or compilation speed?

tests/screenshots/cases/software/basic/text-clipped.slint

ogoffart · 2025-02-20T11:39:00Z

internal/compiler/passes/materialize_fake_properties.rs

+        None => SmolStr::default(),
+    };
+
+    let expr = match (name, builtin_name.as_str()) {


In implicit_layout_info_call called by this function, we we already have special case in other part for the rectangle and empty,

slint/internal/compiler/layout.rs

Line 513 in 705f810

if matches!(

My hope was that then this could be optimized. But this still create something like a { min: 0, max: ...., ... }.min which might not be optimized correctly, and it might indeed be good to handle here.

Otherwise it would make more sense to handle the Image in implicit_layout_info_call as well

Also this might not be working well if the Image contains elements such as
Image{ HorizontalLayout { ... } }

The struct declaration + struct field call gets transformed for sure in the const propagation phase.

Putting it into implicit_layout_info_call would be non-trivial, because it'd need to asssemble a struct that has mostly fixed fields, except the preferred lengths. This would need to be done with either multiple implicit calls, or a non-trivial local variable thing, which is not simplified properly (yet). And where the full layoutinfo struct is needed, it is in fact better to just call the implicit layout info without trying to be smart.

You were right with the Image with children case, I'm going to fix that.

ogoffart · 2025-02-20T13:49:30Z

internal/compiler/llr/pretty_print.rs

@@ -211,6 +211,9 @@ impl<T> Display for DisplayPropertyRef<'_, T> {
            }
            PropertyReference::InParent { level, parent_reference } => {
                for _ in 0..level.get() {
+                    if ctx.parent.is_none() {
+                        return write!(f, "<invalid parent reference>");


Can this actually happen?
I guess it's good to be resilient in this debug code anyway. But it is a bit worrisome if that happens.

Something as simple as cargo run --bin slint-compiler -- -f llr ./tests/cases/widgets/tableview.slint crashes the printer on the most recent master.

I guess there's an actual code generation issue here, but I didn't want to investigate. In fact I didn't want to push this commit at all, but it accidentally happened :D

internal/compiler/passes/const_propagation.rs

badicsalex · 2025-02-20T17:08:30Z

Do you have any numbers on how good it improves the source code size or compilation speed?

I didn't measure code size (and actually don't expect much of a change), but compilation times improved 20-40% for us (i.e. down to 2 minutes from 3). We use tons of conditional elements to implement general components though, which might not be common. This is mainly due to the inlining change. The constant propagation didn't have much of an impact, they are more of a base for the conditional-elimination I want to do.

Looking at CI times, it didn't help the runtime of that all that much.

badicsalex · 2025-02-20T19:08:48Z

I was wrong; executable size for some of our binaries went down by a lot (12MB => 7.2MB in one example, stripped armv7)

ogoffart

Looks good to me. Thanks for this high quality PR.
I think this can be merged.

ogoffart · 2025-02-20T20:12:40Z

internal/compiler/passes/const_propagation.rs

@@ -98,6 +98,29 @@ fn simplify_expression(expr: &mut Expression) -> bool {
                }
                ('|', Expression::BoolLiteral(false), e) => Some(std::mem::take(e)),
                ('|', e, Expression::BoolLiteral(false)) => Some(std::mem::take(e)),
+                ('>', Expression::NumberLiteral(a, un1), Expression::NumberLiteral(b, un2))


Could also work for ≤ and ≥

I was wondering how >= fits in one character, but I guess I got my answer lol

internal/compiler/passes/const_propagation.rs

ogoffart · 2025-02-20T20:15:22Z

internal/compiler/passes/const_propagation.rs

@@ -199,6 +254,30 @@ fn extract_constant_property_reference(nr: &NamedReference) -> Option<Expression
    Some(expression)
 }

+fn try_inline_function(function: &Callable, arguments: &[Expression]) -> Option<Expression> {
+    let Callable::Function(function) = function else {


Note for future improvements: we could also try to inline some built-in functions.

ogoffart · 2025-02-21T10:05:05Z

I did test locally:

cargo build --release -p slint-lsp
11m 03s -> 10m 06s (I think release is especially slow because we specify lto)

cargo test -p test-driver-rust (build time)
43m 25s -> 38m 13s (yes, that's long!)

So we can see about 10% improvements, which is not bad.

Thank you.

tronical · 2025-02-21T13:46:49Z

I've tried this on a code base from a customer of ours, and results are fantastic. The binary size shrunk by ~15% and compile time reduced by almost 50%. But I've noticed an issue: Commit bf716ff now yields a compiler error about a binding loop. I've filed #7693 with the test-case attached.

This reverts commit bf716ff. This exposed the bug #7693 and more issues mentined in #7693 (comment) Fixes #7693 CC #7680

ogoffart · 2025-02-21T17:10:01Z

We decided to revert commit bf716ff for now because of issues mentioned in #7693 (and #7693 (comment) )

The other fixes still bring good improvements.
We may consider bringing this back later because the bug is clearly not in that patch, but more likely a problem in layout with regards to inline items.
So we'll put that commit back at a later point.

badicsalex · 2025-02-21T17:45:36Z

Well, good thing you caught it so fast, I have no problem with reverting commits that break customer code.

Fingers crossed for fixing the other unearthed issues.

This reverts commit bf716ff. (And also revert the test part of 259756c) This exposed the bug #7693 and more issues mentined in #7693 (comment) Fixes #7693 CC #7680

badicsalex added 7 commits February 20, 2025 13:27

compiler: enhance const propagation

aabbeb7

compiler: improve return elimination

17b38d3

compiler: inline functions if possible

188de63

compiler: don't inline repeater components

4ef27e3

They don't need to be inlined, and a lot of the times inlining them incur a significant overhead (e.g. in case of conditional complex components)

compiler: inline components that are used only once

cc6a700

compiler: emit optimized fake properties for Images

9533dd1

compiler: fix pretty print crash on wrong parent references

68a1f3c

badicsalex force-pushed the compiler-optimizations branch from 17ef6c3 to 68a1f3c Compare February 20, 2025 12:27

ogoffart reviewed Feb 20, 2025

View reviewed changes

badicsalex added 5 commits February 20, 2025 18:43

compiler: fix materialize_fake_properties change

1b699e8

compiler: fix func constness propagation

d494603

compiler: Fix function constness marking

14c227e

compiler: add handling for < and > in const propagation

57df760

compiler: add more complicated const propagation unit test

47c0c70

ogoffart approved these changes Feb 20, 2025

View reviewed changes

ogoffart merged commit 3372823 into slint-ui:master Feb 21, 2025
39 checks passed

tronical mentioned this pull request Feb 21, 2025

Failure to compile layout: binding loop reported #7693

Closed

ogoffart added a commit that referenced this pull request Feb 21, 2025

Revert "compiler: inline components that are used only once"

a2e3b94

This reverts commit bf716ff. This exposed the bug #7693 and more issues mentined in #7693 (comment) Fixes #7693 CC #7680

ogoffart mentioned this pull request Feb 21, 2025

Revert "compiler: inline components that are used only once" #7697

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compiler optimizations #7680

Compiler optimizations #7680

badicsalex commented Feb 20, 2025

CLAassistant commented Feb 20, 2025 •

edited

Loading

badicsalex commented Feb 20, 2025 •

edited

Loading

badicsalex commented Feb 20, 2025

badicsalex commented Feb 20, 2025

ogoffart left a comment

ogoffart Feb 20, 2025

badicsalex Feb 20, 2025

ogoffart Feb 20, 2025

badicsalex Feb 20, 2025

badicsalex commented Feb 20, 2025 •

edited

Loading

badicsalex commented Feb 20, 2025 •

edited

Loading

ogoffart left a comment

ogoffart Feb 20, 2025

badicsalex Feb 21, 2025

ogoffart Feb 20, 2025

ogoffart commented Feb 21, 2025

tronical commented Feb 21, 2025

ogoffart commented Feb 21, 2025

badicsalex commented Feb 21, 2025

Compiler optimizations #7680

Compiler optimizations #7680

Conversation

badicsalex commented Feb 20, 2025

CLAassistant commented Feb 20, 2025 • edited Loading

badicsalex commented Feb 20, 2025 • edited Loading

badicsalex commented Feb 20, 2025

badicsalex commented Feb 20, 2025

ogoffart left a comment

Choose a reason for hiding this comment

ogoffart Feb 20, 2025

Choose a reason for hiding this comment

badicsalex Feb 20, 2025

Choose a reason for hiding this comment

ogoffart Feb 20, 2025

Choose a reason for hiding this comment

badicsalex Feb 20, 2025

Choose a reason for hiding this comment

badicsalex commented Feb 20, 2025 • edited Loading

badicsalex commented Feb 20, 2025 • edited Loading

ogoffart left a comment

Choose a reason for hiding this comment

ogoffart Feb 20, 2025

Choose a reason for hiding this comment

badicsalex Feb 21, 2025

Choose a reason for hiding this comment

ogoffart Feb 20, 2025

Choose a reason for hiding this comment

ogoffart commented Feb 21, 2025

tronical commented Feb 21, 2025

ogoffart commented Feb 21, 2025

badicsalex commented Feb 21, 2025

CLAassistant commented Feb 20, 2025 •

edited

Loading

badicsalex commented Feb 20, 2025 •

edited

Loading

badicsalex commented Feb 20, 2025 •

edited

Loading

badicsalex commented Feb 20, 2025 •

edited

Loading