[WASM] SoD Changes #33967
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
The 2 assemblies that increased in size are:
Comparing the
The increase is due to #32374, where ASP.NET is now using System.Text.Json's source generator for its internal types. This means we are in a "worst of both worlds" situation for size because both the STJ reflection serialization and source generation serialization is being used in the app - which means both code paths need to be preserved. However, on a positive note - |
|
Would changing the |
|
If you only ever deserialize, then yes I think it would help. There would be no reason to generate the |
👍 on top of this, dotnet/runtime#54527 might also help reduce a bit of size since the generator would now apply the generation mode specified for a type to other "nested" types in its object graph (rather than use the default of both serialization and metadata). |
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsWhen we went from 6.0.100-preview.6.21318.1 -> 6.0.100-preview.6.21318.5 we saw the below regressions and improvements. Run Information
Improvemnts in SOD - New Blazor Template - Publish
Reprogit clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f netcoreapp5.0 --filter 'SOD - New Blazor Template - Publish*'PayloadsHistogramSOD - New Blazor Template - PublishDocsProfiling workflow for dotnet/runtime repository
|
|
Reading the comments this looks like aspnetcore issue |
|
cc @dotnet/aspnet-blazor-eng |
Agreed. Transferring to |
* Write readers for reading WebEventData JSON payloads * Adding source generators without doing all of the work results in a size increase. We can avoid issues with reflection and the additional size hit by writing bespoke readers. * An additional optimziation this PR includes is to avoid a unicode string -> utf8 byte conversion along with the associated string allocation by using JsonElement as the contract for deserializing JSON payload. At least in the Blazor Server scenario, we could further consider pooling the byte array used for receiving and deserializing the JSON payload making parsing browser events largely allocation free. Fixes #33967
ghost
locked as resolved and limited conversation to collaborators
mkArtakMSFT
added
the
bug
When we went from 6.0.100-preview.6.21318.1 -> 6.0.100-preview.6.21318.5 we saw the below regressions and improvements.
Run Information
Improvemnts in SOD - New Blazor Template - Publish
Historical Data in Reporting System
Repro
Payloads
Baseline
Compare
Histogram
SOD - New Blazor Template - Publish
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository
The text was updated successfully, but these errors were encountered: