Memory usage improvements/optimizations to Messenger

[Sergio0694]

Follow up for #3230, part of #3428

PR Type

What kind of change does this PR introduce?

• Optimization

Overview

This PR includes two main parts: an improvement for the memory pooling buffers, and a refactor of how delegates are registered for message handlers. This last part allows to completely remove local closures for message handlers 🚀

Memory pooling improvements

We're using memory pooling (by relying on the ArrayPool<T> APIs) in the Messenger class to achieve an amortized 0-allocation execution of the Send method in particular (UnregisterAll uses this too). We have code like this:

https:/windows-toolkit/WindowsCommunityToolkit/blob/5bf426523cf456fc13db7b6505c56cad380d5f5f/Microsoft.Toolkit.Mvvm/Messaging/Messenger.cs#L250

https:/windows-toolkit/WindowsCommunityToolkit/blob/5bf426523cf456fc13db7b6505c56cad380d5f5f/Microsoft.Toolkit.Mvvm/Messaging/Messenger.cs#L401

This works just fine, and we do get the 0-allocation after the initial first invocation where we rent the buffer.
There are two downsides here though:

• In the Send method, we rent an Action<TMessage> buffer, so we'll rent a different buffer for every message type
• Given that these types are either internal or not likely to ever by used by consumers of the library, all these rented buffers would only ever by used by the Messenger class itself, and the consumers would not be able to reuse them on their own.

Neither of these points is a big deal and the current implementation is fine, but I think we can do better 😄

Idea: let's leverage the fact that arrays are covariant, and only use a single type to solve both problems, like so:

object[] maps = ArrayPool<object>.Shared.Rent(count);

// Do stuff, example:
foreach (object obj in maps)
{
    var myActualItem = (SomeFancyTypePossiblyInternal)obj;

    // Do stuff with the item...
}

This both allows us to just use object[] arrays, which both reduces the total number of rented arrays (as we can reuse them for different message types), and also makes it so that these rented arrays might potentially also be reused by consumers of the library (should they ever need to pool object[] arrays), further reducing allocations 🚀

Benchmarks

Here are some benchmarks comparing the Messenger from this PR with the one in the Preview1.

Sending messages

Method	Categories	Mean	Error	StdDev	Ratio	Gen 0	Gen 1	Allocated
Old_Send	DefaultChannel	161.7 us	1.52 us	1.43 us	1.00	-	-	-
New_Send	DefaultChannel	153.9 us	1.62 us	1.43 us	0.95	-	-	-
Old_Send	MultipleChannels	148,668.7 us	886.65 us	785.99 us	1.00	-	-	336 B
New_Send	MultipleChannels	138,825.0 us	797.61 us	746.08 us	0.93	-	-	336 B

Performance when sending message is slightly faster than before. Worst case scenario, it's not any slower.

Registering messages

Method	Mean	Error	StdDev	Ratio	Gen 0	Gen 1	Allocated
Old_Register	443.6 us	1.73 us	1.53 us	1.00	113.7695	25.3906	581.53 KB
New_Register	386.1 us	2.47 us	2.31 us	0.87	82.5195	4.3945	381.53 KB

The new version is 13% faster when registering messages, and uses 34% less memory 🚀

Enabled recipient type-specific handlers

One major annoyance for users working with manually registered handlers was the fact that type information was lost.
As in, recipients were registered as just object instances, as it was necessary to cast them in the handler every time.
This PR also changes this by adding support for a type parameter to specify the recipient type.
This enables the following change (which is totally optional anyway, you can still just use object if you want):

// Before
Messenger.Register<MyMessage>(this, (s, m) => ((MyViewModel)s).SomeMethod(m));

// After
Messenger.Register<MyViewModel, MyMessage>(this, (s, m) => s.SomeMethod(m));

Removed local closures

The original implementation used Action<T> for handlers, which caused closures to be constantly created whenever the users wanted to access any local member on the registered recipient. This was because the recipient itself needed to be captured too to be accessed from the handlers. This detail also made it more difficult for other devs to implement IMessenger if they wanted to use a weak reference system. I've replaced that handler type with a custom delegate, called MessageHandler:

https:/windows-toolkit/WindowsCommunityToolkit/blob/32656db1cdd4ddc25e3a88c297ce4062fe64d2ad/Microsoft.Toolkit.Mvvm/Messaging/IMessenger.cs#L10-L22

This delegate also receives the target recipient as input, which allows developers to just use that to access local members, without the need to create closures. The handlers are now essentially static, so the C# compiler can cache the whole delegate too. This is especially useful for the IRecipient<TMessage> pattern, as that was previously creating unnecessary closures when registering handlers - that's completely gone now and delegates are cached there as well 🎉

For instance, you can see that here:

https:/windows-toolkit/WindowsCommunityToolkit/blob/32656db1cdd4ddc25e3a88c297ce4062fe64d2ad/Microsoft.Toolkit.Mvvm/Messaging/IMessengerExtensions.cs#L175-L179

We're now using that cached static delegate (will be able to also explicitly mark that as static when C# 9 lands, but it already is) instead of the method group syntax on recipient.Receive, which allocated a closure for each invocation.

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. Link:
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

[ghost]

Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

Think we could just add the extra checks there in the tests quick, but otherwise think this seems good.

[Rosuavio]

Looks good! 🎊

[ghost]

Hello @Sergio0694!

Because this pull request has the auto merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.