WPF controls render slower on .NET Core 3 compared to .NET Framework 4.8

[AlexChuev]

• .NET Core 3.0 Preview 7
• Windows version 1809
• Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:
According to our performance tests, visual operations take longer to execute in .NET Core 3 compared to .NET Framework 4.8. We were unable to narrow down the issue so far, but it is certainly not connected to the performance issue with the GetCustomAttributes method reported here, since you can see the difference in performance even when all XAML has been parsed (e.g., when scrolling).

Minimal repro:
You can find a small sample with the Data Grid control here: https://github.com/AlexChuev/NetCorePerformanceTest
In the sample, it takes about 30% more time to scroll the Data Grid vertically in a .NET Core 3 project compared to an identical .NET Framework 4.8 configuration.

[rladuca]

First off @AlexChuev thank you very much for reporting this problem. From this we've gotten a much better idea of some areas we need to investigate and ensure we have performance metrics and testing for.

Second, here is an update on where we are with this investigation.

We've narrowed down a few areas where we are seeing performance regressions.

• There are small layout regressions where we are occasionally doing more layouts
• There is a larger issue with text rendering and layout

We are currently focusing on this text rendering and layout case as it is the larger contributor to the problem and we have the best shot at addressing it in a short time frame.

From some experimentation, it looks as if a strong possibility is that an early on split of PresentationCore into two assemblies (PresentationCore and DirectWriteForwarder) might be responsible for this text rendering and layout regression. Replacing the latest split binaries with a merged version from Preview 1, erases the difference. When this is done and the repro app is changed slightly to warm up code paths (as these older binaries are being fully JITed) we are actually faster than .NET Framework.

We're looking into multiple avenues for fixing this, including going back to a single assembly that contains both C++/CLI and C# code (as it is in .NET Framework). We've also engaged .NET JIT teams to investigate if there is something that can be done to improve performance in the case where the assemblies are split.

I'm going to continue updating here and as we move into other perf investigations I will file separate issues.

[weltkante]

Nice work on the analysis, if there's any public issues on coreclr or corefx related to this it'd be great to link them.

[rladuca]

@weltkante Not just yet, we're still getting the lay of the land with respect to exactly what the JIT is doing. If this becomes work in CoreCLR/FX I'll definitely link everything up and make a more technically thorough post here (after appropriate teams have schooled me further!).

[rladuca]

Right now two parallel tracks are running:

• I am attempting to re-merge DirectWriteForwarder and PresentationCore with the latest tooling (much has changed since the Preview1 time-frame). This is blocked on an internal linker error that is being investigated (sorry, there isn't a GitHub bug tracking thing).
• The JIT team is investigating the various perf traces and reproductions with an eye to finding out any differences in how the code is generated between the merged and split case and between .NET Core and .NET Framework.

[rladuca]

I've been able to re-merge DirectWriteForwarder into PresentationCore after getting some linker fixes over the weekend.

Right now we're working on cleaning up some loose ends regarding VS builds, ILLinker fixups, and perf and functional testing.

[rladuca]

We got some good information from the JIT investigation that lead us to re-evaluate what we were doing.

Essentially, it was found that the JIT was not receiving the same params for certain functions. This actually made us look back at the PresentationCore assembly and we found the DebuggableAttribute was being changed due to the post-build IL(D)Asm targets. We were unknowingly turning optimizations off via DisableOptimizations.

We've profile a fix for this and we're getting the same results as in the merged PresentationCore and DirectWriteForwarder scenario. The change is also a one-liner. I'll have a PR out for that soon, and will provide a published repro application that can be tested by others.

[rladuca]

@AlexChuev Can you try these published apps? They contain both fixed and unfixed versions so you can see the difference.

These were built from: https://github.com/rladuca/NetCorePerformanceTest

The Warmup button is there so you can get both cold and warm comparisons.

[AlexChuev]

Thank you for solving this issue, @rladuca. I tested the published app and indeed, there is no difference with a .NET Framework version any more.
We will perform our internal performance tests and let you know the results once we get our hands on a .NET Core 3 build containing the fix.

[rladuca]

Closing as changes were merged into master and release/3.0.

[bugproof]

In my case, my fairly complex WPF app is much slower on 3.0 (GA). When I press some button like "Save" which invokes SaveCommand in my app and HTTP call is made there is a significant delay with 3.0 ... don't know why

[billwert]

@bugproof can you share a sample app that replicates the problem?

[rladuca]

@bugproof Can you also file a new issue for this? This doesn't seem related to this particular bug and a new issue would be needed anyway if this turned into a product fix.

[bugproof]

@rladuca wasn't an issue of WPF (thankfully) but the way HttpClient works in .NET Core. https://github.com/dotnet/corefx/issues/23401#issuecomment-561671803

everything works fine now, HttpClient has to be singleton in .NET Core otherwise it performs badly

[rladuca]

@bugproof Thanks for the follow up, I had seen that issue the other day, but hadn't had the chance to read through it.