-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Blazor Desktop tenets: Performance #2531
Comments
Thanks for contacting us. |
On this, it would be good to check with the WebView2 authors what they consider to be good practice or not. It might be that they already do some pooling of the underlying native resources (processes, etc.), in which case we wouldn't benefit from adding a further layer of pooling. |
@SteveSandersonMS for sure we should talk to them too, but I have a contact in a major product group who says they already do this for perf (rightly or wrongly). So we'll take both answers and average them out 😄 They also pre-load WebView because their app can often anticipate that a new WebView will be needed "soon" so they pre-load it so that it's ready to go by the time it's needed. |
We need to measure the basics in comparison to similar non-Blazor MAUI scenarios:
|
Could you also consider JSInterop Performance? In Blazor Webassembly there is the IJsUnmarshalled Runtime, which allowed up to 250.000 calls per second in our tests. Since in Blazor Hybrid, the communication goes over IPC (At Least in WPF), the number of javascript calls in our tests was limited to arround 1000 calls per second. In Renderloops (Using for example WebGL or WebGPU) that would limit the best case number of calls per frame to 16 at 60fps or 8 at 120fps. |
"Responsiveness" is a key metric but can be difficult to quantitate. Perhaps screen redraw speed of a moderately complex UI. |
SummaryBelow is the list that we are going to measure for GA release.
Delayed until .NET 7
|
I was quite surprised after getting our blazor wasm app working in Maui.NET Blazor hybrid that the performance was actually significantly worse. Is this expected? Is it due to the rendering performance mentioned that is delayed till .NET 7? I had expected to have higher performance since we weren't limited by webassembly and being in IL mode (it was slower and we weren't using AOT). |
@radderz If you're able to provide a minimal repro we can definitely take a look. Otherwise, this is very unexpected. |
@SteveSandersonMS I'll try to put together a repro, its not clear what is the exact cause of the slowness as I haven't delved into it deeply yet but I was expecting the speed to be an improvement. Its always possible we are just doing something wrong, so will try to reproduce it in a simple example. |
@radderz that would be great. Also please let us know what platform it was on, and if it's a mobile device, whether it's a physical device or emulator. There are certainly cases where a debug-built app in an emulator can appear slow because there's various extra debug things going on at various levels (such as more logging). |
@Eilon - It was on both windows and running on windows subsystem for android. They were debug builds but so was the webapp. I am using the mudblazor UI library and the slow down is when deserialising data from OData and updating a grid UI with large amounts of data (the grids are virtualized though). I probably cant setup the example today but I'll try to do it tomorrow. |
@radderz thank you for the extra info. If you can provide a repro for it that will be very helpful so we can try to reproduce exactly what you're seeing. |
Just a bit of an update on where things stand currently. We have added automated coverage for iOS, Mac Catalyst and Android. We're collecting stats on size on disk, size of the unpackaged application, as well as time to first render for Blazor (using the Performance dashboard (requires appropriate permissions) We're working on onboarding the Windows scenario presently. Currently, we can't directly Console log on Windows (#7821 (comment)), which is preventing us from marking the render event like we do on the other platforms. |
dotnet/performance#2526 was just merged earlier this week. That PR handles setting up the Windows environment (installing the WebView), as well as logging the Windows Blazor render event. The data hasn't been reflected on the performance dashboard yet, so we're still ironing some things out to figure out what the missing piece is. |
Performance dashboard (requires appropriate permissions) The .NET MAUI Windows benchmarks are now available for: |
Closing this out now as completed! 😄 |
A feature to consider:
The text was updated successfully, but these errors were encountered: