Skip to content
Nuvyntra Labs

Documentation

Memory and scale

Why popped ViewModels must collect, weak events, and list batching at mid and large scale.

Memory, leaks, and scale

ScaleList sizeGuarantee
Small200Cheap notify; per-item Add is acceptable
Mid5,000AddRange → one Reset
Large50,000Same batching; UI must virtualize (ItemsRepeater / ListView virtualization)

App data is not framework overhead. A 50,000-row product list occupies whatever the Product objects occupy. The framework is responsible for PropertyChanged allocations, CollectionChanged fan-out, whether popped ViewModels are collectable, and whether messengers and commands pin graphs.

  • ViewModel never holds Window or Frame. Lifecycle is a Loaded / Unloaded attached property that unsubscribes on Unloaded.
  • MessageHub default subscribe is weak. The handler must use the recipient argument.
  • Commands are instance fields of the ViewModel and die with it. CanExecuteChanged is a weak event so a popped Button does not stay pinned.
  • Dispose cancels in-flight AsyncModelCommand work.
  • SetProperty equality-exits without allocating a new PropertyChangedEventArgs. PropertyChanged hops to IMainThread when a dispatcher is present.
dotnet test tests/Plugin.WinUI.MVVMExpress.Core.Tests

Discussion

Comment on Plugin.WinUI.MVVMExpress. The thread lives on this component's GitHub repository (nuvyntralabs/Plugin.WinUI.MVVMExpress). Sign in with GitHub — Giscus uses Discussions, Utterances uses Issues.