[Blazor] Rendering performance - Implement SetParametersAsync manually still valid?

[hakenr]

Description

https://learn.microsoft.com/en-us/aspnet/core/blazor/performance/rendering?view=aspnetcore-9.0#implement-setparametersasync-manually

Is the suggestion to replace parameters.SetParameterProperties(this) from ComponentBase with a switch over parameter names still valid?

Given all the ComponentProperties.SetProperties() optimizations, including cached PropertyWriters with Action-based setter delegates, I'm wondering if this advice is outdated.

I ran some tests in Blazor WASM with 10,000 instances of a component in a loop, each having 10 parameters. Overriding SetParametersAsync with a switch-based implementation made no measurable difference.

@guardrex Could you please check with the PU whether it still makes sense to keep this section in the list of potential Blazor performance optimizations? I’m not saying there are no scenarios where this could help, but I think they’re rare enough that documenting this might just lead devs down an unproductive path.

The current text says:

In extreme cases, it can improve rendering performance by 20-25%, but you should only consider this approach in the extreme scenarios listed earlier in this section.

If there are still valid scenarios, maybe we should explain those more clearly than what's currently in that section:

In some extreme cases, you may wish to avoid the reflection and implement your own parameter-setting logic manually. This may be applicable when:

• A component renders extremely often, for example, when there are hundreds or thousands of copies of the component in the UI.
• A component accepts many parameters.
• You find that the overhead of receiving parameters has an observable impact on UI responsiveness.

My test component: https://github.com/hakenr/BlazorPerformanceTuningDemos/blob/e2b1704ac95d9b887f6bd972ac4864c7352b9698/BlazorPerformanceTuningDemos/BlazorPerformanceTuningDemos.Client/ParametersCount/TableCell_ManyParameters_Optimized.razor

PS: This isn't my first attempt at creating a synthetic demo that shows a measurable benefit from this optimization. I've already tried several times in the past without success.

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/performance/rendering?view=aspnetcore-9.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/performance/rendering.md

Document ID

f8a69843-1318-b2de-0161-d4e6a6e34b63

Platform Id

0fb068b6-35c8-9f91-53eb-1695e45cca93

Article author

@guardrex

Metadata

• ID: f8a69843-1318-b2de-0161-d4e6a6e34b63
• PlatformId: 0fb068b6-35c8-9f91-53eb-1695e45cca93
• Service: aspnet-core
• Sub-service: blazor

Related Issues

[github-actions[bot]]

🌱🐇 Spring is here!! 🐣🌻

Stand-by! ... A green dinosaur 🦖 will be along shortly to assist.

[hakenr]

I even considered that if there were a real performance benefit, it might be worth generating SetParametersAsync and parameter assignment via a source generator. But it doesn't look like there's anything to gain from that.

[guardrex]

Thanks @hakenr ... This bit also goes all the way back to when either Steve or Pranav sent this article over about five years ago. I'll ask Dan offline to triage it to one of the PU members.

UPDATE: Done! 👍 I sent Dan a message to see about getting this triaged. If he doesn't respond, no worries. They're all slamming away on .NET 10 priority work. In a week or two if we don't hear back or see an assignment to one of the PU engineers, I'll ping him again.

[danroth27]

Let's ask the experts: @SteveSandersonMS @javiercn Thoughts on removing the performance guidance to Implement SetParametersAsync manually given @hakenr's findings?

[danroth27]

I even considered that if there were a real performance benefit, it might be worth generating SetParametersAsync and parameter assignment via a source generator. But it doesn't look like there's anything to gain from that.

Interesting. We've had https://github.com/dotnet/aspnetcore/issues/29550 on our backlog for a while. I believe originally folks did find that there was a performance gain to be had here. @MackinnonBuck I know you looked at this some previously - thoughts?

[SteveSandersonMS]

The guidance about Implement SetParametersAsync manually isn't specific to WebAssembly, so I don't know whether its claims still hold up in general. We'd need benchmarks on Blazor Server as well (and maybe wasm aot) to get the full picture.

It's good to bring this relatively-old guidance into question though. It's quite possible that runtime improvements have closed the gap between reflection and non-reflection parameter setting since that was written.

[SteveSandersonMS]

BTW more broadly, @hakenr's set of benchmarking scenarios at https://github.com/hakenr/BlazorPerformanceTuningDemos looks great. I wonder if there would be some way to use that in the perf benchmarks that we run in CI.

[danroth27]

BTW more broadly, @hakenr's set of benchmarking scenarios at https://github.com/hakenr/BlazorPerformanceTuningDemos looks great. I wonder if there would be some way to use that in the perf benchmarks that we run in CI.

@lewing

[guardrex]

@danroth27 ... What would you like to do with this issue?

The guidance about Implement SetParametersAsync manually isn't specific to WebAssembly, so I don't know whether its claims still hold up in general. We'd need benchmarks on Blazor Server as well (and maybe wasm aot) to get the full picture.

This doesn't seem actionable for docs anytime soon. Should this be closed in favor of a PU benchmarking issue to investigate further before taking action on docs?

[guardrex]

@danroth27 ... This one still awaits your input ☝️. This doesn't seem actionable for docs at this time. Instead of a docs issue, should this be a PU repo/benchmarking issue for further investigation?