Excessive Memory Usage in Blitz

[NullDict]

Description:
I've observed abnormally high memory usage in Blitz. A simple demo application occupies over 200MB of memory, which is close to the memory footprint typical of Electron-based projects.
Additionally, when the demo is left idle for an extended period (usually over 30 minutes), memory usage drops to around 50MB. This suggests that the additional memory consumption may be due to a bug.
The issue can be reproduced using the todomvc example from the repository (the counter example exhibits the same behavior).

Steps to Reproduce:
Use the todomvc example from the repository
Build with: cargo build --release in the todomvc directory
Run the application
Observe memory usage in Task Manager, memory usage exceeding 200MB

Environment:
OS: Windows 11 Pro (amd64) 24H2 Build 26100.6899
Display Language: Simplified Chinese
Rust: rustc 1.91.0
MSVC: V143
CMake: 4.1.2
Build Configuration: Release mode

When start demo, memory usage observed in task manager.

After idle 40 mins.

[nicoburns]

Interesting. I am aware of memory usage issues.

I have some questions:

• When the memory usage decreases when left idle, does it increase against when interacting with the app?
• How is memory usage with alternative rendering backends? You could try:
  • Vello CPU + Softbuffer: cargo run -rp todomvc --no-default-features --features cpu-pixels
  • Vello CPU + Pixels: cargo run -rp todomvc --no-default-features --features cpu-softbuffer
  • Skia: cargo run -rp todomvc --no-default-features --features skia

[NullDict]

Interesting. I am aware of memory usage issues.

I have some questions:

• When the memory usage decreases when left idle, does it increase against when interacting with the app?

• How is memory usage with alternative rendering backends? You could try:

  • Vello CPU + Softbuffer: cargo run -rp todomvc --no-default-features --features cpu-pixels
  • Vello CPU + Pixels: cargo run -rp todomvc --no-default-features --features cpu-softbuffer
  • Skia: cargo run -rp todomvc --no-default-features --features skia

I tested various build options and tried adding 10 todo items.
It appears that the Vello CPU + Softbuffer configuration delivers the best memory performance, while the Skia build exhibits serious bugs.
I am still testing the behavior after re-interaction once the memory usage of the default build drops, and I'm waiting for its memory footprint to decrease.
It's worth noting that memory usage may vary depending on the system and CPU model.
Compared to my current PC with a Core i9-12900HX running Windows 11 Pro, the default build shows worse memory performance on my other PC equipped with an AMD 5560U running Windows 10 Pro—its memory usage at startup exceeds 400 MB.
However, the Vello CPU + Softbuffer build still maintains excellent memory performance on this system, using no more than 20 MB.
The Skia build similarly suffers from apparent memory leak issues.
Additionally, I noticed that some dependencies have been changed to be sourced directly from GitHub—I'm curious if this is to experiment with certain new features using pre-release dependencies.

When starting

After add 10 todo

[NullDict]

After memory usage decreases, re-interacting with the application does not cause a significant increase in memory consumption. I discussed this phenomenon in Chinese developer communities, where some users reported that on macOS, memory usage does not decrease even after leaving the application idle overnight.

[altacountbabi]

there also seems to be a memory leak with resizing on the skia backend, on linux with wayland

[nicoburns]

Switching the WGPU setup code to use MemoryHints::MemoryUsage has improved this a bit, but hasn't completely solved the problem.

[niminypiminy]

Check drivers. WGPU abstracts over Vulkan/DirectX/Metal/OpenGL. Out-dated drivers will allocate extra buffer.
On my windows 11, I am seeing 135mb.
on linux 85mb.
windows extra overhead obviously due to drive caching.
i have 183 files. it's not a trivial app.
15mb binary. all using dioxus native.
so far everything is working, but with occasional workarounds mostly due to CSS limitations as outlined in docs.