Any expectations for executable size and ram usage ?

[BlackSharkfr]

Hello,

I am just starting with iced.
I barely made by first iced application : the simple usual "hello world counter app" kind.

I am checking how iced compares with my previous experiences with other rust based GUI crates :

• how easy is it to do the basic things
• cpu / gpu usage when clicking, moving, resizing stuff
• ram usage
• how much extra bloat do I need to ship for GUIs which don't use the native OS GUI,...

So far, I find iced very pleasant to use, it seems to use both cpu and gpu reasonably (a hello world counter app is far from realistic a stress test).
However, i am now looking at the executable and ram usage, and I have a few questions.

Compiling my simple counter application for Windows 10 :

With debug profile, i am expecting things to get a little bloated, and that's indeed what I obtain :
exe size : 14MB, ram : 90MB

With cargo's --release flag and adding #![windows_subsystem = "windows"]. The executable shrinks considerably, ram usage only a little. I'm not really satisfied.
exe size : 6MB, ram 76MB

Further compiler optimisations : opt-level = "z" and lto = true yields a smaller executable : 3.1MB but no change on ram usage

Now, trying features : the biggest ram impact I found was using features = ["glow"] instead of using wgpu.
exe size : 1.5MB, ram 27MB
However, I do notice the different behaviour, and performance impact on the application, especially when moving the app around on a secondary monitor. It looks like wgpu supports gpu acceleration across all monitors, but glow does not. (CPU usage spikes from low single digits to double digits when moving and resizing on monitor #2)

Do these numbers look realistic to you ? Am I missing something ?

As far as storage goes. A few megabytes isn't super efficient but i am aware iced doesn't have the benefit of being an OS native thing. So I understand the minimum size will never be as small as a native app. So a few megabytes if fine for me a resident desktop app. I wonder about ram usage though... Specially for such a simple counter app.

So far, I only built my "hello world counter" app for Windows 10, so I do not know how these values translate for other OS and/or web.
How do iced applications scale with bigger applications ? Are these minimum bloats a one-time thing you have to deal with just because that's the fundamental infrastructure iced is based on, and anything above is lightweight or do bigger iced apps grow really fat later ?

What explains the large difference in ram usage between wgpu and glow ?
Are there any targets to make iced applications lighter ?

[SkyfallWasTaken]

@BlackSharkfr did you manage to get an answer?

[BlackSharkfr]

I have not received a reply.
And I haven't tried iced again since my message.

[airstrike]

I sincerely hope the memory usage of the counter example isn't the reason why you haven't tried iced, because that would be a tragic outcome.

[airstrike]

Are these minimum bloats a one-time thing you have to deal with just because that's the fundamental infrastructure iced is based on, and anything above is lightweight or do bigger iced apps grow really fat later ?

The former. A lot can be attributed to the graphics buffers for WGPU. The use of the words "minimum" and "bloat" together is a bit of a headscratcher...

Memory usage is just not an issue at all.

In fact, to my knowledge, there is not a single issue or discussion on GitHub, Discourse or Discord about actual "bloated" iced apps. Yet, for some reason, this question keeps being asked by people running very short, contrived snippets like the counter example and then thinking it's taking up too much memory.

I'm not picking on this specific discussion. This is the third time I've seen this question asked in less than a month.

I appreciate the value of being inquisitive, but I sincerely hope people aren't reading posts like this and drawing incorrect conclusions from incomplete information.

You've stated yourself that a counter example is not a realistic stress test, so it's inadequate for this type of investigation.

I encourage you to leave the memory usage profiling to a real benchmark or to real-world issues if and when you run into them—in which case I'm willing to bet the memory issues will come from application code, not from iced.