maui: Memory leaks EVERYWHERE

We’ve moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

I think this is on the right track: https://github.com/dotnet/maui/pull/13260

If you keep navigating back and forth from master to its details and watch memory usage, you will see memory raising

Hi, the problem exists since Xamarin. And you can find similar bug reports for MAUI. I think this problem will me moved to “Backlog milestone” as always.

I remember that result can differ from debug and release. So you can test it on release version just to be sure.

Between the memory leaks and the inefficiency of the CollectionView and other controls, and the Shell having minor bugs, how can we trust MAUI?

This is so sad.

@jsuarezruiz @PureWeen @jamesmontemagno @maddymontaquila @davidortinau same problem on Xamarin Forms

We spent 3 weeks, 2 developers trying to figure out why the pages are not cleaning up. Unable to find. We just see in the Xamarin Profiler that the Resource Dictionary memory increases

If you keep navigating back and forth from master to its details and watch memory usage, you will see memory raising

Hi, the problem exists since Xamarin. And you can find similar bug reports for MAUI. I think this problem will be moved to “Backlog milestone” as always.

I remember that result can differ from debug and release. So you can test it on release version just to be sure.

Hi @jamesmontemagno @PureWeen @jsuarezruiz @samhouts

Please, when we are going to have this update #13327 in .net 6 and .net 7??

It seems like I found something.

Snapshot 2:

WeakReference<Microsoft.Maui.Controls.BindableObject>
Count: 1,545
Bytes: 37,080

Snapshot 10:

WeakReference<Microsoft.Maui.Controls.BindableObject>
Count: 1,657
Bytes: 39,768

I will keep investigating.

Same problem. I have only one question. How to work with MAUI with such bugs?

As I said above. We have the same problem on Xamarin Forms on a large application. We have 15000 daily users for enterprise application. Xamarin Forms support is until May 2024. Please fix and don’t forget Xamarin Forms users. @jonathanpeppers @jamesmontemagno @PureWeen @jsuarezruiz

Will take a look to move the changes to Xamarin.Forms.

I have the same problem. cc: @PureWeen

As I said above. We have the same problem on Xamarin Forms on a large application. We have 15000 daily users for enterprise application. Xamarin Forms support is until May 2024. Please fix and don’t forget Xamarin Forms users. @jonathanpeppers @jamesmontemagno @PureWeen @jsuarezruiz

@symbiogenesis I have big app ready for production and I can’t release it because it goes from 200 MB to 2000 MB in matter of a few minutes of using it. It’s by far the biggest problem I encountered as there is no workaround. It’s not data objects being stuck, it’s all just UI bits being held by strong references from brushes, gesture handlers and god knows what else. The problem is really serious. No events or things like that are causing my memory leaks. I either make sure to detach events or make them as a weak reference.

There isn’t an excuse for memory leaks on the platform, but the patterns that are likely to cause memory leaks are likely not great patterns for normal workloads. You shouldn’t be abusing query parameters, for instance. And the leaks aren’t any worse than Xamarin.Forms was. In my case, XF was worse. Until the platform bugs are fixed, the best you can do is focus on your own code.

Events are one of the most likely causes of leaks, and those can be solved if you implement WeakEventManager. That one is pretty easy to do.

I had seen worse leaks from the handlers in XF, particularly inside of CollectionViews. You could scroll and just watch the memory usage rise and rise endlessly. I think a lot of those issues were solved with MAUI. I don’t see this at all with my app.

Premature optimization is a bad idea. Unless your app has a known memory issue, there is no reason to assume that it does. For me, converting from XF to MAUI caused a measurable and dramatic decrease in memory usage.

As I said above. We have the same problem on Xamarin Forms on a large application. We have 15000 daily users for enterprise application. Xamarin Forms support is until May 2024. Please fix and don’t forget Xamarin Forms users. @jonathanpeppers @jamesmontemagno @PureWeen @jsuarezruiz

Will take a look to move the changes to Xamarin.Forms.

Changes already available in latest Xamarin.Forms SR.

when will you update it for .net6 ? this is a serious and urgent problem need to be solved. thank you

Hi @jonathanpeppers, Thanks for the fix of this bug. We have the same bug on Xamarin Forms. Can you do a PR also for Xamarin Forms. Thanks

From @8m0

I think this problem will be moved to “Backlog milestone” as always.

This one made me laugh more than expected after I saw the bot moving this thread to the backlog milestone

I din’t expect Xamarin to be memory leak proof because it wasn’t a tech from Microsoft at first. But I expected MAUI to be better. Far better than its current state about momery leaks…

I tried this app: https://github.com/Vroomer/MAUI-master-detail-memory-leak.git

Using latest dotnet/maui/main. I changed one thing, just to try to make the GC button slightly better:

private async void Button_Clicked(object sender, EventArgs e)
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    await DisplayAlert("Done!", "Done!", "Ok");
}

Then I took an initial snapshot, and did CollectionView click, Pop page, Force GC getting a memory snapshot each time:

(notice the flat memory graph)

Initially, my thought that I would see new instances of these appearing (and that was the leak):

• Giant array: Bytes = new byte[1024 * 400000]
• DetailPage objects
• Entry objects
• Other WinRT objects

However, I don’t see any of these objects being leaked.

To cross-verify this, I ran dotnet gcdump collect -p 29096:

https://devblogs.microsoft.com/dotnet/collecting-and-analyzing-memory-dumps/

Opening the dump, I see the expected bytes (and it does not grow as I navigate more):

I am not really seeing a problem currently with this sample & dotnet/maui/main.

Does anyone have a suggestion of something else I can try?

I will try the latest stable MAUI bits.

Just wrote a comment about the problem under @jamesmontemagno latest video, the comment was deleted within 1 min.

I do not believe I deleted any of your comments, most likely auto moderated. I don’t check comments that often.

Hello, thanks for the answer. Could you do something regarding to the problem? It’s very important problem which always got pushed to Backlog milestone.

Just wrote a comment about the problem under @jamesmontemagno latest video, the comment was deleted within 1 min.

@angelru, I recommend swapping out your controls (particularly CollectionView) with those from Syncfusion, DevExpress, or one of the other providers, and seeing if that fixes it. The free demo versions of those controls should help you answer that question without committing to purchasing. Better than not shipping.

This post inspired me to try to fix up some open source CollectionView-based controls, like Maui.DataGrid, with about a dozen PRs, but after having done so, it is clear that if the record counts are very high then you will see noticeable leaks with the platform handlers almost regardless of what you do on your end.

The open source controls I linked to earlier will probably work for some use-cases, though. Might need to get your hands dirty with PRs.

You were right. I replaced CollectionView with SfListView from Syncfusion and the problem is gone, no more memory leak when refreshing the VM and scrolling. Already got a Syncfusion community license, so now I can keep working

If you keep navigating back and forth from master to its details and watch memory usage, you will see memory raising

Hi, the problem exists since Xamarin. And you can find similar bug reports for MAUI. I think this problem will be moved to “Backlog milestone” as always. I remember that result can differ from debug and release. So you can test it on release version just to be sure.

That resembles exactly what I’ve seen in the Xamarin forms issue board. I suspected that they carry over a lot of bugs, which „conveniently“ for them do not (yet) exist in Maui issue tracker. Xamarin/Maui Team focuses on adding new features for shell, etc. these features are usually broken from the beginning. And they ignore severe existing issues. Only tiny bugs get fixed. And some bugfixes are so bad/lazy that you want to scratch your eyes out.

This will not change, until some MS Manager forces it‘s team to use Maui for a production app.

No official MS product uses Xamarin.Forms or Maui. Guess why. Cause they know how bad it is, and avoid it like the plague. And they know that there is no way to reason with the Xamarin/Maui team, about how far away they are from a production quality framework. Why Maui team has the perspective that they delivered the best thing ever, and many issue-tickets are an indicator of the good quality of Maui.

I am very frustrated with MAUI, I proposed it at the company I work for as a good framework for cross platform app development. But we find memory errors and disastrous performance in very important controls that prevent us from taking an application to production.

Looks like this custom ListView control advertises that it avoids memory leaks

https://github.com/Keflon/FunctionZero.Maui.Controls

This one may also be useful, but only for Android and iOS:

https://github.com/roubachof/Sharpnado.CollectionView

this one also seems promising:

https://github.com/Redth/Maui.VirtualListView

I loaded up thousands of records into a CollectionView today, and noticed that the scrolling on WinUI was actually smooth. Android and iOS were bad.

Looks like the recent PRs https://github.com/dotnet/maui/pull/12627 and https://github.com/dotnet/maui/pull/12660 will be helping.

Some tricks to try now include:

• Set constant and explicit heights everywhere possible
• Set ItemSizingStrategy to MeasureFirstItem if possible
• Set CompressedLayout.IsHeadless to true where possible
• Set the Binding mode to OneTime where possible

These tricks are all used by @angelru already, but not everyone may be aware.

In addition to those tricks and the aforementioned WeakReferences for events, other things to try:

• Initialize collections early all at once, if possible, instead of adding a lot of records to the public property after it is created.
• Cache complex objects and dynamic UI objects where possible, using something like a ConcurrentDictionary