-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: WinUI 3.0 and XAML Performance #1517
Comments
This may be completely irrelevant, but retargeting the SDK takes forever for the XAML UI project, this may be a performance issue for VS itself though, not sure where it lies. I had my reasons for retargeting, I know it may sound really weird. |
Here are my performance issues, when it comes to UWP:
|
Please don't use XAML ambiguously in discussions. "XAML Performance" could refer to the parsing of XAML files or it could refer to the performance of the WinUI framework. My guess is that this thread is about the latter. On UWP performance, this is very good at the moment in release mode using .Net Native. I expect that with .Net 5 it will be similarly fast using AOT. I am concerned that in the meantime with .Net Core 3.0 it will become slow again. It would be great if UWP with .Net Core 3.0 would work with CoreRT which is very similar to .Net Native. |
@charlesroddie Your comment is about the initial discussion, or my comment? |
About the initial post and title, but applies to a lot of threads in this repo. |
I guess you are talking about Release build times right? The Release build is so slow because of .NET Native. It makes build times much slower, but gives you major improvements in startup times, XAML rendering (data binding) and memory usage. In Debug mode, apps should usually build pretty fast, so this does not really affect development cycles that much IMO. At least, I usually only build Release every now and then, so for me this is not a problem (I am a big fan of .NET Native performance gains).
I agree that StorageFolder/StorageFile API is a major painpoint for any file driven application. I don't believe that this is caused by sandboxing, it is probably more a problem of how the API is designed. Every instance contains these properties: Attributes, DateCreated, DisplayName, DisplayType. In the old FileInfo API, these would only be retrieved on-demand on first access. But in UWP all of these properties are always retrieved as soon as an instance is created, which makes the API so much slower when you enumerate large folders. It works well if you only access files every now and then (like, open one file through file dialog). But apps that work with a lot of files and folders will have major performance hits due to the bad API design. UWP really needs a fast, light-weight file API that pretty much only wraps the file name (and maybe some file permission token). Then there should be an async method to create the "fat" StorageFile/StorageFolder instances from it, or open streams directly, on demand.
I have seen things like this, but I don't think that async is really the cause of these problems. Normally, exceptions from async code are handled very well. The bigger problem might be that you usually don't see any call stack from native platform code, so if the platform calls back into user code and things fail there, you sometimes don't even know why or how things have failed, where in WPF you would always see a clear stack trace of how your code was invoked.
Did you try with VS performance tools? They work very well for me. |
@lukasf Thanks for replying!
I'm talking about Debug times, without .Net Native. For me .Net Native generated a weird crash a while ago, and I haven't tested it since. My project in Debug x86 (it is slightly faster than Debug x64), usually takes 30-40 seconds to compile. Once again, this is build 17783 - I have read on the internet that lower builds generate faster time - I think it's on your uservoice forum.
I couldn't agree more. Or, much simpler maybe - just allow access to System.IO for all HDD ;) That would simplify things a lot. My app displays photos/videos from user's folders, making it easy for him/her to select his favorites to edit them to create another video - in WPF, this fast simply insanely fast. In UWP, this is beyond slow.
It is possible that this is the issue, but it does make debugging a huge pain...
I will definitely try them. I used dotTrace a low with WPF, and isolated errors insanely fast. Will definitely try the VS performance tools - just read an article about them, seems they should fit my needs. |
In our case we are using UWP for a LOB app and we have found big performance issues in two common scenarios:
Things come worse in this scenarios if you don't have a powerfull machine or any other windows process is requiring CPU, most of our users are using i5 or i3 with 8Gb of RAM and the performance with this hardware is very bad, there is continuous hangs of several seconds on this environments Here is a sample project which try to show this two issues: |
@jtorjo If you want good file performance, there is one thing you should be aware of: Enumerating files usually involves lots of async calls. Every single "await" on the UI thread is very slow and will cost you about 10ms. This is just the "await", with no actual work being done. So for bigger file operations, it is highly recommended to not await every single async call on the UI thread. You can do that by adding ConfigureAwait(false) on every async method call, or by running the whole file IO stuff on a background thread. I use the latter, since it is easier to implement:
Now all the countless await calls inside ReadFilesAsync will not be awaited on the UI thread but on the background thread (which is very fast). Only the final result is awaited once on the UI thread, and then it can be used on UI tread and for data binding. Be careful to not access UI stuff in ScanFilesAsync(). The same concept is useful for other complex file or stream operations, like reading or writing stuff in a loop, where you have lots of await calls. Put that in a background task or use ConfigureAwait(false) and you will have much better performance, close to classic .NET APIs. |
@lukasf Thanks for the advice. I wish that were true. That was also my idea - to just do it in another thread. But in my tests, the gain is close to 0%. About a new file API is required: I just don't understand why MS won't simply allow System.IO over all HDD, once you've requested broadSystemAccess. It's clearly possible, since if I write a Desktop Bridge app, I can use System.IO all over the place, and it's fast as hell. Best, |
I agree. I started to reply, but decided it makes sense to take this to another discussion (specifically related to compilation performance): Related links. |
@jtoro I have heard this from customers that this would be preferable (and I have to agree). I think the appropriate place to have this discussion is in the xlang project, and I opened this issue a while back for this exact issue https://github.com/microsoft/xlang/issues/484. Please go comment/upvote if you'd like to see that 😄 |
nobody talks about navigation performance of cached pages with a large visual tree? Why a cached page needs so much time to be rendered again? For us this is more important than shadows, lights, or rounded corners... @jevansaks you pointed me to start a discussion here, but I don't see any interest in improving performance, and I think there is a lot of work to be done in this area. |
Just as as jtorjo mentioned, the compiling of UWP/C# projects is many times slower than WPF(even in release mode and the .NET Native checkbox is unchecked), which is very frustrating for me. Hope WinUi can change this. |
@danzil @fabiant3-zz - FYI for compiler/tooling performance. @bartekk8 @Austin-Lamb - FYI for runtime performance. Looks like there is another discussion on compiler performance here. @asierpn If you have a specific scenario (navigation) that is not performant, can you please open an issue with a repro so it can be investigated independenty ? |
We're well aware that UWP/WinUI project compile performance, including full and incremental builds, can be way better and we're taking steps to make it so. Issue #1535 that Ranjesh mentioned tracks that. |
@danzil As an FYI, the more recent of a Windows version you're targeting, the worse the compile time. Right now, I'm targeting 1903, and just the deployment itself takes 6+ seconds! (no building at all). On 1809, deploment was less than 1 second. Here are a few other notes:
|
@jtorjo thanks for adding your experience! We've got all these issues in mind as we're designing the upcoming performance improvements in XAML compilation. |
@danzil Cool! Trust me, I'm more than looking forward to any improvements you guys may have. Probably on a daily basis, I'm wasting at least 45 minutest just compiling/deploying stuff. |
@danzil Any ETA on this? Compile times are simply insane... Me, and I'm sure anyone doing UWP, would love anything -- like, gradual improvements! And we'd be the first to test them. Thanks! |
I totally understand it's painful and I'm sorry I can't give you better news. Right now, my understanding is that it will likely take several more months before the team could start working on an implementation for this problem. @LucasHaines may be able to help with a more precise ETA or plan. |
@LucasHaines Could you please share an ETA? Thanks! |
@danzil, @stevenbrix, as noted here: https://github.com/Noemata/XamlBenchmark UWP has slipped behind WPF in rendering performance. I didn't think that was possible?? Clearly, a lot can be done to improve performance. Why is WPF now faster? Why have we not seen any performance gains in UWP of late? Why is WinUI so very slow? Despite the .Net Native compiler being slow, I'm still a big fan. With a rational code segregation scheme when designing a larger app, it's possible to greatly diminish the pain of a rebuild for release. So for those experiencing lengthy rebuilds, you probably need a better understanding of your apps dependency tree in order to fix your rebuild issue. .Net Native is surprisingly good at this stage. Everything but UI should live in .Net Standard libs. Take a look here for how this helps: https://github.com/Noemata/FakePOS |
I second that. When I upgraded to the lasted WinUI 2.5, my app started 8 times slower! (compiled 3 times slower) I simply had to revert to WinUI 2.3 to make this bearable again. |
Very useful benchmarks @Noemata
Your WPF is dotnet5 non-AOT while UWP is netnative (AOT based on netframework), and netframework -> dotnet5 gives more of a performance boost than non-AOT -> AOT. Ideally we would have dotnet5 + AOT. |
@charlesroddie , WPF's performance gains are quite impressive indeed. I opted to remove one part out of the benchmark, and that's raw compute, since it's not a fair comparison. .Net Native still outpaces .Net 5.x when compiled for release. So the performance picture is more complicated than can be gleaned by looking at the surface details. Not sure what all the tweaks consisted of (jitter, libs, etc.), but .Net 5.x + WPF is more than the sum of its parts. It's also quite impressive how the .Net team managed to maintain stability throughout the different releases. Given that most of the benchmark is happening at the rendering layer which is mostly driven by machine code (shoud be seeing way more GPU activity), I would expect UWP to be fastest. Clearly, UWP has not gotten as much attention lately. The .Net Native compiler has received some needed tweaks of late and is looking pretty good. It's not flawed as much as it is limited to constraints that require careful design choices when using reflection. It's a shame it's not being progressed further. Fingers crossed that WinUI will some day reach WPF+.Net 5 level of stability. Microsoft will need to re-invest in UWP. At least until they come up with a better alternative to CsWinRT. |
It's a bit embarrassing, but I got the tests results for WinUI and UWP wrong. I won't make any excuses, should have known better than to do all my testing inside the debugger. VS2019 has a significant performance drag on both UWP and WinUI (about the same for both). When running outside of VS2019, UWP is still fastest. About 3 times faster than WinUI. WinUI's numbers are a lot better, but still sluggish compared to UWP. WPF perf is respectable nonetheless. I've revised my posted results. |
@jtorjo could you collect some traces for your case in both 2.3 and 2.5 ? Here are the instructions.
@bartekk8 as FYI. |
@ranjeshj , thanks for the info. What I was looking for was an apples to apples performance comparison to see how WinUI fairs when compared to UWP. Performance tooling can be used to evaluate perf, but first you need a well constructed test scenario that touches the areas of interest in a way that doesn't skew results. Initially, I was only looking to evaluate basic XAML rendering times for WPF/UWP/WinUI; XAML primitives only. I'll leave it to experts like yourself to do the nuanced analysis. I'm only looking for big picture real world applicable results. Here's another example of a tool I put together to do LOB related sorts of testing: https://github.com/Noemata/RosettaNavigation I'm more interested in the performance/validation suites Microsoft uses. I find those more telling because I can see the API surface being traversed during the test. API interactions are often quite surprising. |
@ranjeshj Yes, will do, but it will be a good few days before I can do that. I'm already behind everything on launching my app. As soon as I have a few hours, I'll do it. As a side note, the first thing I wanted to do was to do some profiling, but I ran into the other Windows bug (https://developercommunity.visualstudio.com/t/No-Data-in-CPU-Usage-Tool-Windows-Updat/1384519). I lost several hours getting my system back into a decent state, I got insanely nervous and reverted everything. So, I will do this ASAP, since I clearly want this fixed -- for me upgrading with these performance drops is simply out of the question.
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Discussion: WinUI 3.0 and XAML Performance
During the WinUI community call, there was a comment about improvements coming to the performance of XAML Rendering with WinUI 3.0
I thought I would start a discussion thread where people could collate performance quirks they have come up against, but for my own view, I would just like to ask if the team working on it, could write up some blog posts talking about what improvements are being made, along with the Alpha release, as well as how the process extracting the stack from the OS, enables ongoing improvements in the future.
The text was updated successfully, but these errors were encountered: