Perf: Minimize Reflection: Custom ComWrappers for WinUI

The ComWrappersSupport.InitializeComWrappers method in WinRT.Runtime.dll has this summary:

/// <summary>
/// Initialize the global <see cref="System.Runtime.InteropServices.ComWrappers"/> instance to use for WinRT.
/// </summary>
/// <param name="wrappers">The wrappers instance to use, or the default if null.</param>
/// <remarks>
/// A custom ComWrappers instance can be supplied to enable programs to fast-track some type resolution
/// instead of using reflection when the full type closure is known.
/// </remarks>
public static void InitializeComWrappers(ComWrappers wrappers = null)
{
   ComWrappers = wrappers ?? new DefaultComWrappers();
}

Anything that can “fast-track…instead of using reflection” sounds like exactly what we want for WinUI - I’m just not exactly sure what this would look like. Is this something that needs to be generated by WinUI - or can cswinrt provide this for us? If WinUI needs to generate these wrappers, what would one look like for something like DependencyObject?

[jkoritzinsky]

I believe this should be provided by WinUI.

This is primarily focused around RCW generation. When the DefaultComWrappers instance gets an RCW, it tries to figure out the .NET type from the results of GetRuntimeClassName() and then instantiates an object via reflection/expression trees. The implementation does a lot of reflection and is definitely not fast. WinUI could provide an implementation that overrides the default RCW implementation to directly map a runtime class name to a type with a series of if checks or a switch statement on a string and directly instantiate an object without reflection.

This could be done two ways:

1. Static definition for WinUI types: This would speed up all built-in WinUI types and could live in WinUI’s managed DLL definition, but wouldn’t help speed up user types. Additionally, because WinUI has so many types, this implementation would be quite large and most of it would likely never be used in a user application.

2. Definition generated during the build: You could use a tool such as the IL Linker to discover the type universe of the application and generate a ComWrappers instance for the application that is specific to the application’s type universe. This would be smaller (since WinUI has a ton of types and most aren’t directly used in managed code in most applications) but more challenging to implement (since you’d have to generate IL instead of C# or do a two-phase compilation model). This approach is similar to what .NET Native can do today since it knows the whole type universe of the application. And unlike .NET Native, you could still have a fallback to the base implementation that uses reflection if the tool didn’t catch every type (for example if an application follows a plugin model).

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.