Perf: Minimize QueryInterface calls, implement FastABI (Consumption)

[Scottj1s]

Background

WinRT API designs are class-based, but interfaces are used to collect the API surface into versioned units. For mature APIs, such as WinUI and IXP, that means objects will implement many interfaces. Use of those interfaces creates overhead in several ways:

1. Runtime performance overhead due to having to QI and Release for the interfaces.
2. Increased memory consumption for caching interface pointers.
3. Binary growth due to code generation for QI-ing for multiple interfaces.

FastABI addresses these problems by generating a "flattened" default interface, appending methods for all non-default exclusive-to interfaces (e.g., IButtonBase*) across the inheritance hierarchy for the runtime class, through a well-defined algorithm. This flattened interface is a superset of the default interface and is thus backward compatible with it for unenlightened client code. The class implementation is still responsible for responding to QI calls on non-default exclusive-to interfaces for unenlightened clients. These QIs are typically implemented as fast, lightweight COM tear-offs using the C++/WinRT fast forwarder library. Client code that is built with FastABI-enabled language projections look for a "fastabi" attribute attached to a runtime class in metadata, using it to generate the corresponding flattened vtable layout, enabling FastABI gains in client code. So, FastABI benefits only accrue when both server (class implementation) and client are FastABI-enabled.

Consumption

For C#/WinRT, the primary benefit for FastABI is on the client (consumption) side, complementing the support in native APIs like WinUI. This issue is about implementing C#/WinRT FastABI support on the client side, as described above, comprised of these steps:

1. Generating the flattened default interface based on the FastABI algorithm.
2. Dismantling the lazy querying and caching of non-default exclusive-to interfaces in generated class code.
3. Adding FastABI-enabled classes to test components (TestWinRT preferably, as this is a language-general feature).
4. Testing FastABI-enabled classes in the unit test project.

Authoring

As described, FastABI provides the biggest returns for complex class hierarchies with multiple versions of exclusive-to interfaces. A conscious tradeoff is made for implementing these interfaces as COM tear-offs instead, "lazily" allocating them on demand. Whether this applies to C#/WinRT authored classes, and whether tear-offs can be as efficiently implemented, is an open question. It seems unlikely that C#/WinRT authored types would ever approach the complexity of WinUI, for example. We may conclude that it makes little sense to implement FastABI authoring support in C#/WinRT.

[angelazhangmsft]

We can open up another issue for FastABI (Authoring) if that becomes a need or priority.