OSes
Bittersweet post tells devs what they already knew: The framework is too slow
Microsoft claims to have achieved a “leap forward” in performance for WinUI 3, the current native framework for Windows apps, with a 25 percent improvement for the parts of File Explorer coded using this framework.
Software engineer lead Beth Pan posted figures for the WinUI portion of File Explorer, showing 41 percent fewer memory
allocations and 45 percent fewer function calls. She added that some
optimizations “involve small or large breaking changes,” so they will
be opt-in at first for developers using the framework. The plan is for the optimizations to become the default in future versions of WinUI and the Windows App SDK,
with opt-out available when needed.
WinUI 3 is currently measurably slower than both WPF and UWP… this is NOT OK
The new optimizations are part of a push to make Windows
more responsive. In March, Windows boss Pavan Davuluri promised to improve the quality of the operating system, including a commitment to a “faster
and more dependable File Explorer.” His post noted that Microsoft intends
to “move more experiences to WinUI 3” for faster responsiveness.
Pan’s post is bittersweet for developers. Performance issues
with WinUI 3 have been well known for years.
Although Microsoft calls it a native framework, that is a stretch. WinUI 3 is based on WinRT (Windows Runtime), a component interface first used in Windows 8 that sits between application code and the underlying Win32 API, which has a better
claim to being native. An advantage of WinUI 3 is its support for Fluent UI, the Windows
design system. Developers using WinUI 3 get the Windows 11 look and feel, but
not the best performance.
“WinUI 3 is currently measurably slower than both WPF
[Windows Presentation Foundation] and UWP [Universal Windows Platform]… this
is NOT OK,” said one comment. Another said that “you can’t build a WinUI app and call it smooth at the same
time.”
Component vendor DevExpress has also posted about WinUI 3 performance issues. The company stated that WinUI component architecture
has the potential for fast rendering and animation, but that “unfortunately, each action within a component requires
WinRT interop, which is slow.”
These concerns undermine Davuluri’s hope that using
more WinUI 3 will fix Windows 11 performance, unless the framework itself is
improved, as Pan now claims.
Another longstanding gripe among Windows devs is that Microsoft’s developer division has created frameworks that the Windows and Office teams have not always adopted consistently. Internal tensions go back many years. Some may still remember early builds of “Longhorn,” the code name for Windows Vista, having to be reworked before Vista’s eventual release in 2007 because of performance issues with .NET. This caused distrust of .NET in the Windows team. “What
you need to do is actually use your framework across the company,” said another comment. Pan replied, insisting “that’s the push.”
This is exactly what developers using WinUI 3 want to hear, but the
long and tangled history of Windows UI frameworks suggests that a consistent and
enduring company-wide approach is unlikely. ®
