Perf: managed interop overhead

[stevenbrix]

Creating this issue so this can be tracked. There's nothing I have in mind at the moment that needs to be addressed immediately.

Basically what I found was that in the simple repro app provided (see #1633), the managed app had 10x worse perf than native. Digging into the issue showed that 25% of the time was due to GC caused by Xaml. While this app was not the best of benchmarks, we need to understand this problem better, and figure out where these types of issues do occur in an app, and how the new interop layer in .NET5 will affect this.

See Bug #1633 for more discussion on this issue.

[stevenbrix]

From #1633

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.

@MikeHillberg, I didn't test out this scenario, because I didn't think we recommended developers to use these APIs? I feel like it's important to measure the actual scenarios. Or do you think that will help narrow down the issue?

The GC overhead I'm referring to is from Jupiter calling out to .NET through the IReferenceTracker interfaces. I was thinking this was mostly due to the event args types, but I don't want to speculate any more, and would prefer to get more factual data

[jtorjo]

@stevenbrix
You said in the other thread:

Hopefully with cs/winrt we can improve this, although unlikely in the WinUI3.0 timeframe.

That would be prety sad, because using dependency properties is a must in any decent app. I'm using it heavily in my apps. I'm pretty sure this would be a blocker for me and for others.

[ranjeshj]

@stevenbrix Are these mainly allocations that is causing the overhead ? Are there any low hanging transient allocations that we could avoid ? @bartekk8, this would be a good scenario to track performance on.

+1 on improving GetValue. Looking at GC overhead of XamlDirect.GetInt32Property might provide some clues.

[stevenbrix]

Are these mainly allocations that is causing the overhead ? Are there any low hanging transient allocations that we could avoid ?

It's a little early to tell. It's definitely due to allocations of some sort, and it would probably be good to look into XamlDirect.GetInt32Property to see if this is mostly due to boxing or the creation of event args. Or we could measure the current scenario, but not use a custom DP with a callback (to avoid event args creation).

Hopefully with cs/winrt we can improve this, although unlikely in the WinUI3.0 timeframe.

That would be prety sad, because using dependency properties is a must in any decent app. I'm using it heavily in my apps. I'm pretty sure this would be a blocker for me and for others.

@jtorjo I just mean by the time we release WinUI3. The unfortunate reality is that we have a lot of work, and not a lot of time. The nice thing about .NET5 and cs/winrt is that we'll own this whole interop story, so we can own our destiny moving forward. We're just getting to a point where we can start to prototype some of these interop scenarios, I'll circle back once we know more.

[jtorjo]

I just mean by the time we release WinUI3. The unfortunate reality is that we have a lot of work, and not a lot of time. The nice thing about .NET5 and cs/winrt is that we'll own this whole interop story, so we can own our destiny moving forward.

@stevenbrix I can imagine it's a lot of work. I was a bit circumspect from the start that we'll see a WinUI 3 so soon.

Having said that, if I were to use WinUI3 from a non-sandbox model, once WinUI3 is released, will I suffer from the same issue as outlined by this bug, or will this be 100% UWP/WinRT related?

(I'm assuming it's the former, but just want to be sure)

[stevenbrix]

Having said that, if I were to use WinUI3 from a non-sandbox model, once WinUI3 is released, will I suffer from the same issue as outlined by this bug, or will this be 100% UWP/WinRT related?

(I'm assuming it's the former, but just want to be sure)

@jtorjo - correct, this doesn't really have anything to do with the sandbox. It's still unclear what the characteristics will be in WinUI3, we should know more soon.

[zenjia]

Hi, I've just created two UWP projects(one with Winui, another is native UWP) , copied the code and run the test. The perf results of the two are almost the same -- about 300x faster than Winui/Desktop, but still 10x slower than WPF! Does anything changed when Winui was decoupled from UWP code? Maybe we can find some clue by looking into the original UWP code.

[Noemata]

@zenjia , one thing that has changed is the influence Visual Studio has on UWP and WinUI perf. Not sure when this happened, but you will get very poor results when evaluating performance while a process is attached to Visual Studio. For some reason, WPF is not affected to the same degree. Would be helpful to know what option can be disabled to eliminate this bottleneck.

If you run your tests outside of Visual Studio, results are significantly better. There are other artifacts Visual Studio is adding to the mix which make it hard to use VS for tuning purposes.

[pratikone]

a lot of work has been done in perf side of things in last few years. can you check back if it is still as bad. I assume there always be some gap but 10x gap seems like a lot. I am closing it for now for being stale. If you find the perf to be this bad, feel free to re-open it.