Discussion: Dependency property is much slower in WinUI 3 than in WPF

[Xarlot]

Based on my quick test WinUI 3 dependency property nearly 50 times slower than in WPF.
https://github.com/Xarlot/dependencypropertytest
Do you have any plans to improve this behavior?

[jevansaks]

Great feedback, thanks for calling this out! Closing gaps like this with WPF is certainly a goal. @Austin-Lamb is on the hook to investigate.

[Austin-Lamb]

@Xarlot - thank you for making such a minimal repro, that is greatly appreciated :) I'm about to go on vacation for Thanksgiving, so I won't be able to get to this until early December, but I'm putting it in my queue and will get back to you.

[Xarlot]

any news?

[stevenbrix]

@danzil are you aware of the issue of not being able to build Release apps?

@Austin-Lamb are you alright if I take this? I'd be hesitant on doing any further investigation at the moment. Debug builds don't use the .NET Native toolchain, so the better comparison would be to use UWP w/o WinUI and test Release vs Release. However, that might even be a moot point because the current plan of record is to move to .NET5, which has a different interop layer, and we need to be cognizant of the perf implications of that.

I'd also be curious to see what the time is for a c++ app and whether the C++/C# boundary is causing major issues in a test like this.

[ranjeshj]

tagging @bartekk8 since this is related to perf.

[danzil]

@stevenbrix Are you referring to the issue that when you target SDK 10.0.17763.0 you get an internal compiler error when building release (this test project targets that SDK and fails to build Release)? I have not seen that error previously, but if you build against a newer SDK like 10.0.18362.0 it works fine.

[Austin-Lamb]

@stevenbrix - this is about runtime perf rather than build perf, so I'm going to assign it over to @bartekk8

[stevenbrix]

@Austin-Lamb i'm not sure this is runtime perf. in a regular c++ app i'm seeing it's much faster (by about 10x). I'm thinking this might be because of the interop layer, which is something that I'm looking into validating we don't regress with CS/WinRT

[stevenbrix]

I think we may want 2 issues. We are definitely slow, a C++ app is around 400ms, which we can definitely improve on. But a C# app is about 3500-4000ms on my machine, so we need to make sure the interop layer is much more efficient.

[MikeHillberg]

This in part is likely boxing overhead, the kind of thing that would be helped by using XamlDirect.GetInt32Property rather than DependencyObject.GetValue.

[stevenbrix]

@MikeHillberg, @AaronRobinsonMSFT looked at this the other day and found that there is a lot of GC overhead that we are causing, most likely due to the high amount of allocations. Hopefully with cs/winrt we can improve this, although unlikely in the WinUI3.0 timeframe.

[stevenbrix]

I've created #2028 so we can track the managed interop layer. We should move any discussion about that there, and let this issue stay related to DependencyObject.SetValue perf, which was still much worse for native WinUI apps than WPF

[MikeHillberg]

You're seeing GC overhead even when using XamlDirect.GetInt32Property instead of GetValue? GetInt32Property is typed so that boxing isn't necessary, which saves a lot of allocations.

[stevenbrix]

You're seeing GC overhead even when using XamlDirect.GetInt32Property instead of GetValue?

No, just with DependencyObject.SetValue. Let's continue discussion on the other issue, so this can stay focused on DependencyObject.SetValue perf and not related to interop overhead.

[Xarlot]

We definitely can use more efficient API. Thanks for the hint.
However, we expect the new framework to be faster and more efficient. What the point of the new framework if it`s slower than 10+ years old predecessor (WPF)? ;)

Looking forward to net core 5 integration

[SeRgI1982]

Could someone from Microsoft comment on this discussion?
People invest a lot of time, energy, and above all, money.
After a year and a half of investing in a project written using WinUI, decision-makers are wondering if it was really a good idea.
I bet that discussions like this are happening not only in my project.
As people who have trusted you, we deserve a few words that will calm our nerves.
Concrete details provided in the present, not an indefinite future.

Something like this could give us more than no comments from your side:

"I apologize, guys, we messed up, but we know where the problem lies, and we will work on resolving it by version 1.5"

or

"It's not up to us; it depends on another team that plans to address it in the coming six months, which will make WinUI faster."

[ADD-Eugenio-Lopez]

Our problems of performance will be solved with the new version of Windows App SDK 1.3.2 (1.3.230602002), specifically with the application initialization and openening new forms. The speed increase has been drastic.

I recommend trying teh new version Windows App SDK 1.3.2.

[SeRgI1982]

Our problems of performance will be solved with the new version of Windows App SDK 1.3.2 (1.3.230602002), specifically with the application initialization and openening new forms. The speed increase has been drastic.

I recommend trying teh new version Windows App SDK 1.3.2.

Thank you @ADD-Eugenio-Lopez for the quick response.

Currently, we use ver. 1.3.230502000 and opening a Page with grouped data inside DataGrid takes ages (it is only one example).

[ruben2s]

So, we should stick with WPF for performance? Plus some library to make the app look more modern such as wpfui?

[sjb-sjb]

@MikeHillberg @Austin-Lamb @stevenbrix @BorzillaR where is Microsoft on this issue? Most of the recent comments seem to be from users in the community rather than status updates from Microsoft. Is MS taking action on this?

[zadjii-msft]

(I'm not actually on the XAML team so don't @ me, but...) I did find the following internal work items tracking this:

• MSFT:32447326
• MSFT:27845732
• MSFT:29010461

(I however don't understand the internals of XAML enough to really be able to parse those threads)

[Neme12]

Why was this converted to a discussion? Seriously? This seems like a serious issue.

[Neme12]

What a better way to show that the WinUI team doesn't care about perf at all. Meanwhile .NET these days tries to squeeze out every last drop of perf as much as they can with every release and it's a huge priority for them, but apparently WinUI on the other hand doesn't care at all, and are OK being 50x slower than even the old .NET Framework that didn't get the enormous perf improvements that .NET (core) did...

[Neme12]

And this is NOT only an issue with interop. The C++ version is still slower than WPF.

[Neme12]

I guess I'm not surprised that the Windows/WinRT people don't care about perf. :/ From my experience with UWP and WinRT, the WinRT APIs are enormously slow compared to their Win32 equivalents, sometimes by a factor of more than a 100. Meanwhile, they avoid using .NET because they think .NET is too slow.... while their C++ based WinUI is 50 times slower than .NET's WPF. Oh the irony...

[legistek]

I mean, most of the crappiness of WinUI is leftover from compromises they had to make to support the Surface RT, so I think performance was actually their main concern. They seem to know that binding is a problem though, which is why they do everything they can to deter us from using it and leave out things like MultiBinding. I assumed this was because reflection into a .NET module initiated from the C++ side is really slow compared to simple reflection in .NET, but if even native C++ WinUI is slower than WPF, as people are saying, that is surprising and makes no sense.

[legistek]

@Xarlot's benchmarks with the newest 1.5 SDK, 64-bit Release mode, Intel Core i9:

WinUI
Write - 775
Read - 34

WPF
Write - 32
Read - 3

So about 20x difference for write and 10x for read.

Obviously much better than before but still pretty friggin abysmal considering WPF does all this in purely managed code.

For WinUI if I remove the property change callback - which is the interop from C++ to C# - write drops to around 150-200. So the interop may not be the whole problem but it's still a huge source.

[legistek]

I also added another test for binding (changing the value via a bound view model rather than a direct DP set):

WinUI - 2000
WPF - 103

So still overall about a 20x difference on the write side, with the change handler.

So one very big takeaway here is not to add a change handler when it's not needed.

[gmurray81]

I mean don't denigrate managed code here, it gets jitted. What I assume we are paying for is the managed to native boundary that exists in WinUI for these scenarios. Something about that must be chatty enough and involve enough tax that it really adds up. So as I said above, either that tax needs to be lowered or the managed to native seams need to be moved to less chatty areas. Or just do it all managed like WPF and put the managed to native seams somewhere with really low chattiness.

[legistek]

So every DP value is stored as an IInspectable, even constants. I guess if you're using C++/WinRT you need to use box_value with great frequency. Here it is:

    template <typename T, std::enable_if_t<!std::is_convertible_v<T, param::hstring>, int> = 0>
    Windows::Foundation::IInspectable box_value(T const& value)
    {
        if constexpr (std::is_base_of_v<Windows::Foundation::IInspectable, T>)
        {
            return value;
        }
        else
        {
            return impl::reference_traits<T>::make(value);
        }
    }

So what's reference_traits?

From https://devblogs.microsoft.com/oldnewthing/20221215-00/?p=107595

template <typename T>
struct reference_traits
{
    static auto make(T const& value)
    { return winrt::make<impl::reference<T>>(value); }
    using itf = Windows::Foundation::IReference<T>;
};

reference is simple enough and seems pretty low overhead, but it also doesn't implement IInspectable. It must be winrt::make doing that. Here it is from base.h:

    auto make(Args&&... args)
    {
#if !defined(WINRT_NO_MAKE_DETECTION)
        // Note: https://aka.ms/cppwinrt/detect_direct_allocations
        static_assert(std::is_destructible_v<D>, "C++/WinRT implementation types must have a public destructor");
        static_assert(!std::is_final_v<D>, "C++/WinRT implementation types must not be final");
#endif

        using I = typename impl::implements_default_interface<D>::type;

        if constexpr (std::is_same_v<I, Windows::Foundation::IActivationFactory>)
        {
            static_assert(sizeof...(args) == 0);
            return impl::make_factory<D>();
        }
        else if constexpr (impl::has_composable<D>::value)
        {
            impl::com_ref<I> result{ to_abi<I>(new impl::heap_implements<D>(std::forward<Args>(args)...)), take_ownership_from_abi };
            return result.template as<typename D::composable>();
        }
        else if constexpr (impl::has_class_type<D>::value)
        {
            static_assert(std::is_same_v<I, default_interface<typename D::class_type>>);
            return typename D::class_type{ to_abi<I>(new impl::heap_implements<D>(std::forward<Args>(args)...)), take_ownership_from_abi };
        }
        else
        {
            return impl::com_ref<I>{ to_abi<I>(new impl::heap_implements<D>(std::forward<Args>(args)...)), take_ownership_from_abi };
        }
    }

This is as far down as I dare go lest I become lost and never return, and I confess I don't know what 2/3 of that stuff does, but it looks pretty complicated and there's obviously more. And this, mind you, is all just to assign a value to a DP.

I'm no expert in how the .NET runtime is implemented either, and so don't know how this compares to the overhead of boxing and unboxing value types. I do know that WPF uses some performance hacks of its own like creating static objects representing boxed true and false to cut down on this, which I don't see much of here.

So does it seem plausible this is 20x slower, or takes 20x as many CPU instructions, as the CLR doing the same thing (bearing in mind the CLR is by definition also doing its thing in native code)? I'd certainly say so, especially after reading this: https://mihai-albert.com/2019/12/15/boxing-performance-in-c-analysis-and-benchmark/.

But what I keep coming back to is, if the performance issues really go this deep, I don't see realistically how they fix them without starting over.

[contextfree]

Yeah, but if you want to use WinUI from safer lower-level languages such as Rust or Swift without having to involve a .NET runtime, you still need something like WinRT to call its APIs from those languages. (In fact the company behind the Arc browser recently ported it to Windows using WinUI 3, and developed and open sourced a Swift WinRT projection as part of this)

[legistek]

I mean, if adding type safety to an unmanaged language makes you slower than just using a managed language, that really doesn't help make the case for the unmanaged language.

you still need something like WinRT to call its APIs from those languages

We had it. It was (and still is) called COM. WinRT is just COM with extra overhead that would otherwise be handled by a runtime (and much more efficiently, it appears).

[sylveon]

It must be winrt::make doing that.

The implementation for IInspectable and IUnknown comes from winrt::implements, which winrt::impl::reference inherits from. winrt::make just creates an instance of winrt::impl::reference using new

[legistek]

Ahh thank you. Specifically root_implements in base.h is where the meat is. There's ... a lot ... going on there.

[hez2010]

I managed to get WinUI 3 run with NativeAOT. With the latest WinUI 3, now the result on the aot-compiled app is:

WinUI
Write - 411
Read - 27

WPF
Write - 21
Read - 2

Still about 20x difference for write and 10x for read. Apparently the slowness happens on the native code, I think the same performance character should be observed on a C++ WinUI 3 app as well.

[legistek]

For the WinUI write did that include the C#-based property change handler? I'd be curious of the result without. (Even with AOT I'm sure the interop still carries substantial overhead).

[Neme12]

Why aren't they taking this seriously at all? If anything, this just shows how unserious they are about WinUI.

[legistek]

I don't know that they're not. Clearly there's been a huge improvement since the 1.0/1.1 SDK. It might just not be possible to do any better without starting from scratch, which I'm sure is a decision well above the paygrade of anyone monitoring github.

[hez2010]

@legistek

WinUI 3 (WASDK 1.5) vs WPF

Test	WinUI 3 with JIT	WinUI 3 with NativeAOT	WPF
Get	103ns	137ns	10ns
Set	1035ns	1079ns	70ns
Set (with handler)	3732ns	3954ns	72ns
Set (the same value)	903ns	1044ns	42ns
Set TextBlock.Text	326ns	239ns	129ns
Set Border.Background	779ns	670ns	139ns

Seems that WinUI indeed gets performance improvements as version growing. It's still slower than WPF but WASDK 1.5 is way faster than WASDK 1.1.

[sylveon]

A significant chunk of this slowness comes from CsWinRT, and is not from WinUI's native code. Here are results with the same benchmark written in C++ (which removes that overhead). I took the liberty to fix a bug where it was only doing 100k writes and not 200k (because of a i++ in the loop body, which I replaced with i + 1). I also removed the property changed callback, to give C# the best chance.

All tests where ran on a Ryzen 9 5900X, using x64 Release mode and running without a debugger. Latest WASDK 1.5.

WinUI 3 - C# .NET 8 JIT (don't know how to get AOT working):
Write - 347
Read - 27

WinUI 3 - C++/WinRT:
Write - 136
Read - 16

FWIW, these results are still miles better than UWP, here are the results in UWP:

UWP - C# .NET Native:
Write - 737
Read - 53

UWP - C++/WinRT:
Write - 300
Read - 100

Considering WinUI 3 is derived from UWP XAML code, this is considerable improvement already. And realistically, I suspect the current numbers are fast enough for most apps out there.

C++ benchmark code in case anyone wants to try it:

template<typename T>
struct TestClass : DependencyObjectT<TestClass<T>>
{
    DependencyProperty TestProperty()
    {
        static const auto prop = DependencyProperty::Register(L"Test", winrt::xaml_typename<T>(), {L"TestClass<int>", Windows::UI::Xaml::Interop::TypeKind::Custom}, PropertyMetadata(winrt::box_value(T{})));

        return prop;
    }

    T Test()
    {
        return GetValue(TestProperty()).as<T>();
    }

    void Test(T value)
    {
        SetValue(TestProperty(), box_value(value));
    }
};

void MainWindow::Button_Click(IInspectable const&, RoutedEventArgs const&)
{
    const auto testClass = make_self<TestClass<int>>();
    const auto before = std::chrono::high_resolution_clock::now();
    for (int i = 0; i < 200000; i++)
        testClass->Test(i + 1);

    const auto after = std::chrono::high_resolution_clock::now();
    const auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(after - before);
    Title(winrt::to_hstring(duration.count()));
}

void MainWindow::Button_Click_1(IInspectable const&, RoutedEventArgs const&)
{
    const auto testClass = make_self<TestClass<int>>();
    const auto before = std::chrono::high_resolution_clock::now();
    int test = 0;
    for (int i = 0; i < 200000; i++)
        test += testClass->Test();

    const auto after = std::chrono::high_resolution_clock::now();
    const auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(after - before);
    Title(winrt::to_hstring(duration.count()));
}

[legistek]

In other words 100% native WinUI is maybe 5x slower than 100% managed WPF. I think that speaks for itself.

[sylveon]

This has nothing to do with native vs managed, but everything to do with a poor implementation. It would be as slow even if purely managed.

[SeRgI1982]

You're right - it doesn't matter. In the end, the result is poor, which means that the sunset of XAML-based technologies is slowly approaching as there are no sensible alternatives 😟

[legistek]

Well the problem is they implemented it in a native language but tried to give it the type safety of a managed language except without a runtime or 20 years of optimization and learned lessons. You get the impression looking at it that someone just thought, "it's C++ so I don't have to worry about performance. Let's have 15 layers of vtables just for fun!" The result is 100s or 1000s of CPU cycles just to box a value.

@SeRgI1982 Avalonia is fine if you can get past the IMO arbitrary syntax changes from WPF (I couldn't).

[MartyIX]

Perhaps @DarranRowe can comment on this thread.

[DarranRowe]

Beyond the slowness of virtual calls tends to be serverely overstated?
I'm actually of the same opinion as @sylveon here.

To give a concrete example, I created a project that places a C++ class with an interface with a virtual member in a DLL. The purpose of doing this is to remove the devirtualisaiton that will happen if the compiler can see the complete class definition.

struct istringgetter
{
	virtual std::string get_string() const = 0;
};

struct string_getter1 : public istringgetter
{
	virtual ~string_getter1() = default;

	virtual std::string get_string() const override;
};

istringgetter &get_string_getter();

These functions are defined as follows:

static std::unique_ptr<string_getter1> s_string_getter;

std::string string_getter1::get_string() const
{
	return "string_getter1";
}

istringgetter &get_string_getter()
{
	if (s_string_getter == nullptr)
	{
		s_string_getter = std::make_unique<string_getter1>();
	}

	return *static_cast<istringgetter *>(s_string_getter.get());
}

This is interesting, because the compiler is also constructing the string object. The get_string_getter function also only returns the interface.

The main C++ function is:

int wmain()
{
	LARGE_INTEGER start{}, end{}, freq{};
	istringgetter &gs = get_string_getter();

	QueryPerformanceCounter(&start);
	std::string s = gs.get_string();
	QueryPerformanceCounter(&end);
	QueryPerformanceFrequency(&freq);

	uint64_t time_taken = ((end.QuadPart - start.QuadPart) * 1'000'000'000) / freq.QuadPart;

	std::println("{}", s);
	std::println("{}ns", time_taken);

	return 0;
}

As you can see, the timing is only around the get_string member. The assembly generated for this call is:

00007FF64E2F3381  mov         rcx,qword ptr [rbx]  
00007FF64E2F3384  mov         r8,qword ptr [rcx]  
00007FF64E2F3387  lea         rdx,[rbp+27h]  
00007FF64E2F338B  mov         rcx,rbx  
00007FF64E2F338E  call        r8  
00007FF64E2F3391  nop  

So it is certainly going doing a virtual call through the interface. If it had devirtualised it, the compiler would be pulling out the vtable earlier and there would only be a single move at the start.

The output I get from this is:

string_getter1
200ns

It hovers around 100-300ns.

Now, for the ironic thing here. Suppose I use a concrete C++ class without a virtual call.

struct string_getter2
{
	std::string get_string() const
	{
		return "string_getter2";
	}
};

If all I do to the main function is swap the type:

int wmain()
{
	LARGE_INTEGER start{}, end{}, freq{};

	string_getter2 gs{};

	QueryPerformanceCounter(&start);
	std::string s = gs.get_string();
	QueryPerformanceCounter(&end);
	QueryPerformanceFrequency(&freq);

	uint64_t time_taken = ((end.QuadPart - start.QuadPart) * 1'000'000'000) / freq.QuadPart;

	std::println("{}", s);
	std::println("{}ns", time_taken);

	return 0;
}

This actually ends up taking A LOT LONGER.
The output of this is:

string_getter2
5400ns

It can hover between around 4 and 10 microseconds. But this example is around 5 and a half microseconds. A factor of 10 slower than the virtual call. The thing is, this concrete version properly inlines the call too:

00007FF7D516337B  movups      xmmword ptr [rbp+27h],xmm0  
00007FF7D516337F  mov         qword ptr [rbp+37h],rbx  
00007FF7D5163383  mov         qword ptr [rbp+3Fh],rbx  
00007FF7D5163387  mov         r8d,0Eh  
00007FF7D516338D  lea         rdx,[string "string_getter2" (07FF7D518E6C8h)]  
00007FF7D5163394  lea         rcx,[rbp+27h]  
00007FF7D5163398  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Construct<1,char const *> (07FF7D51650C0h)  
00007FF7D516339D  nop  

While it isn't an exhaustive test, this test was performed on a Ryzen Threadripper 7960x, so your results may vary. But any kind of cost associated with virtual calls may not be a factor, and other costs, like any posts that Raymond Chen may post end up being about other factors, like being able to use move semantics and other native C++ tricks that you can't do on the IVector interface.

[hez2010]

I built the nightly version of CsWinRT (which has a bunch of optimizations compared to the current latest one) and did a simple benchmark on both in-proc WinRT call (calling a method in native dll through WinRT ABI) and managed direct call (calling a managed method directly without inlining) to calculate 12+34 in async and sync, respectively.

This is the result:

Async in-proc WinRT call: 309,119.0108191654 op/s
Async managed direct call: 5,221,932.114882506 op/s
Sync in-proc WinRT call: 136,239,782.01634878 op/s
Sync managed direct call: 3,787,878,787.878788 op/s

Just note that in-proc WinRT call slower than direct call is apparent as it needs to cross the managed-native boundary. It's the same with calling a method defined in a native dll through P/Invoke.

As you can see calling a method through WinRT ABI is generally 10x-20x slower than calling a managed method directly. This performance is quite attractive if we are talking about foreign language interface call.

WinUI 3 is a native UI framework which means a method cannot be called directly like WPF, any call to the framework must go though any form of native ABI (either C ABI or WinRT ABI or else).

IMO at the point of WASDK 1.5, most optimization has been done and the else we can do in the future is little. The performance degradation we are seeing is that we are paying for the cost of native interop.

Update: #9154 (reply in thread)

[legistek]

Yes root_implements in base.h. I found it thanks to you. But if you think that's not very complex I think we have a different definition of complex. And there are even deeper function calls invoked there that I don't have the patience to try to hunt down the code for.

Remember we are talking about every local DP value - int, bool, string, etc. - being boxed inside one of these.

We're trying to figure out why 100% native DP setting in WinUI is ~5x slower - even when all interop is removed - than the equivalent test run in WPF. This is what your results show. You really find it so hard to believe that the total number of CPU cycles needed to box a value in this way isn't 4-5x what the CLR (again, also running native code, and optimized to high heaven by the best of the best) does when it boxes a primitive value to an object?

The 100% native benchmark should blow WPF out of the water. That it doesn't means something is very, very inefficient at a deep level. Given that IInspectable boxing is so ubiquitous that seems like the place to be focusing. But if you don't think that's it then what's your theory?

[sylveon]

Here's a full implementation of the IInspectable methods for an IReference, this is what the cppwinrt metaprogramming mumbo jumbo ultimately emits - minus input validation:

HRESULT GetIids(ULONG *iidCount, IID **iids)
{
    static const IID impl_iids[] = { __uuidof(IPropertyValue), __uuidof(IReference) };

    *iidCount = 2;
    *iids = impl_iids;

    return S_OK;
}

HRESULT GetRuntimeClassName(HSTRING *className)
{
    return WindowsCreateString(L"Windows.Foundation.IReference`1<Int32>", 38, className);
}

HRESULT GetTrustLevel(TrustLevel *trustLevel)
{
    *trustLevel = BaseTrust;
    return S_OK;
}

IInspectable is not some omega complex heavy thing - it is merely a slim interface over COM's IUnknown. Pointing the blame at WinRT is easy, however the defect is not with WinRT or its usage but with the implementation of DPs.

You really find it so hard to believe that the total number of CPU cycles needed to box a value in this way isn't 4-5x what the CLR (again, also running native code, and optimized to high heaven by the best of the best) does when it boxes a primitive value to an object?

Because it's not - allocating a few bytes for the wrapper is cheap. The following code takes 30ms to execute (it could also be optimized further, I've identified a way to drop it down to 8ms by directly allocating winrt::impl::reference rather than calling PropertyValue::CreateInt32):

winrt::Windows::Foundation::IInspectable ref = nullptr;
for (int i = 0; i < 200000; i++)
    ref = winrt::box_value(i + 1);

That's 200k successive boxings. It is a minor part of the ~130ms total runtime for 200k property sets. Something else is wrong. I've already pointed out CsWinRT as a potential cause for C#, but ignoring that, I would have to profile the implementation itself to know more.

[legistek]

30ms isn't trivial.
How long does this C# code take to run on the same machine? For me it's 2ms

    object o = null;
    for (int i = 0; i < 200000; i++)
    {
        o = (object)i;
    }

[sylveon]

For a more apples to apples comparison, using a direct allocation of winrt::impl::reference<int> rather than a call to PropertyValue.CreateInt32 reduces the time to 8ms (it's normal for C# to win in allocation speed). I've created an issue for this: microsoft/cppwinrt#1416, but it only helps C++ consumers.

However, that still leaves 100ms unaccounted for in our original DP write benchmark. That comes from the WinUI DP implementation. Boxing is not the core issue - ignoring its cost, performance is still not at satisfying levels.

[legistek]

Ok yeah I'm not suggesting that the actual boxing accounts for all the write time. Obviously it doesn't. Nor does boxing account for all the write time in WPF either.

However I am saying that it's useful to compare the speed and complexity of IInspectable boxing with the speed and complexity of WPF/C# object boxing because both are a necessary and ubiquitous component of DP writing in those respective platforms. It's reasonable to hypothesize that whatever performance ratio we see there may roughly carry over to rest of the write operation as a whole, at least to within an order of magnitude. And sure enough, that's exactly what we seem to be seeing - the same 4-5x performance penalty ratio seems to exist in WinRT boxing vs. .NET boxing that also exists in pure C++/WinRT vs. pure WPF DP writing. I don't think that's a coincidence.

You're asserting that the cause of the discrepancy is in the DP implementation generally, but I looked at that as best I could, and it seems to mirror the WPF implementation reasonably closely, all the way down to EffectiveValueEntry. And this makes sense if Silverlight was a C++ port of WPF and WinUI was an evolution of Silverlight.

The main differences between the WinUI vs. WPF implementations are in the use of IInspectable for everything vs. object for everything. And so if I'm playing detective and I'm looking for something that can account for the total speed difference, it's natural to hone in on something that affects everything.

Likewise my criticism is not the use of WinRT/IInspectable in general. It's using it for everything. I bet D3D would grind to a halt too if every vertex and vector implemented IUnknown, let alone IInspectable.

[legistek]

More information on WinRT's general efficiency problems compared to vanilla C++:

https://devblogs.microsoft.com/oldnewthing/20240301-00/?p=109468

The reason is that the Windows Runtime types are all virtual interfaces, which means vtable calls for all the methods which cannot be inlined or optimized. Whereas C++ library types have a richer set of available methods to allow you to write simpler code, and since they are written in C++ itself, the compiler can perform optimizations that aren’t available to virtual methods.

[sylveon]

Windows.Storage is notorious for being slow.

[ChaimCL]

Windows.Storage is notorious for being slow.

I'm curious about what's going to happen to the Microsoft.Storage.ApplicationData API that WASDK is going to release, I hope it's a lot better.

[brabebhin]

That seems to be a replacement for Windows.Storage.ApplicationData which was one of the least bad portions of Windows.Storage.

[sylveon]

Ehhhh, its had its fair share of annoying bugs that still annoy me to this day (because we love people running old operating systems without backported fixes)

[DarranRowe]

Windows.Storage is notorious for being slow.

I'm curious about what's going to happen to the Microsoft.Storage.ApplicationData API that WASDK is going to release, I hope it's a lot better.

Honestly, with the specs published, it doesn't look too bad.
Any potential performance issues with ApplicationDataContainer could be ignored because you would imagine that the it is only really intended for a small amount of settings. ApplicationData itself would only really need to compose paths. There would be nothing stopping you from using the regular desktop API in a desktop application for any other I/O. I think you can see it as having a similar role to SHGetKnownFolderPath as well as providing access to the ApplicationDataContainer.