dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.46k stars 10.03k forks source link

Blazor Server RenderBatchWriter should stop defensive copies of RenderTreeFrame on Write method #25764

Open SteveSandersonMS opened 4 years ago

SteveSandersonMS commented 4 years ago

In .NET 5, RenderTreeFrame stopped being readonly in order to support some performance optimizations focused on WebAssembly. Generally this did not have any drawbacks because:

However there remains one other case: RenderBatchWriter's Write method:

void Write(in RenderTreeFrame frame)
{
    ....
}

Inside there, it performs lots of property reads. If this blog post about perf implications of in is correct, that means there will be lots of defensive copies happening.

To fix this, we could either remove the in modifier and just have a single copy made for each call to Write, or we could replace in with ref and have no copies made.

I don't yet have any specific measurement of the perf effects. We should at least try to measure this before committing to a specific resolution. It might not really have any observable real-world effects because RenderBatchWriter is so fast anyway relative to other things that are going on, such as transmitting render batches over the network.

ghost commented 4 years ago

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

ghost commented 4 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

ghost commented 10 months ago

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.