Blazor Wasm - Size regression in System.Text.Json.dll

[SamMonoRT]

System.Text.Json.dll.br has a big spike in last two days as observed in https://msit.powerbi.com/groups/me/apps/54e0e83f-07bc-45bf-87b7-a7677ff3af2a/dashboards/fa051820-ff60-4d40-8a08-bdcc1b47b1d0

@eerhardt @CoffeeFlux

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

System.Json.Text.dll,br has a big spike in last two days as observed in https://msit.powerbi.com/groups/me/apps/54e0e83f-07bc-45bf-87b7-a7677ff3af2a/dashboards/fa051820-ff60-4d40-8a08-bdcc1b47b1d0

@eerhardt @CoffeeFlux

Author:	SamMonoRT
Assignees:	-
Labels:	arch-wasm, size-reduction
Milestone:	-

[eerhardt]

@eerhardt suggested that these 2 changes are possible offenders

#50778
#51025

@layomia @steveharter @eiriktsarpalis

[layomia]

These two changes are primarily JsonConverter-based features and are very likely to have caused the regression.

The JSON source generator will help reduce size for apps that use the new overloads that take pre-generated metadata (#51300). The converters for these features will be trimmed out if not needed in an app, and if the new serializer methods are used instead of the existing ones.

I don't expect the size regression here to be reversed until the JSON serialization logic within Blazor assemblies is refactored to use the new serializer methods. See these commits for an early attempt. Happy to help with this effort.

[SamMonoRT]

Thanks @layomia - do we know if there is any tracking issue for the refactoring work ?

[SamMonoRT]

cc @mkArtakMSFT - is this on your team ?

[SamMonoRT]

Want to put this note out, to make it very clear - We don't expect any changes from dotnet/aspnetcore#31877 to be backported to Preview 4. But we need to make sure the necessary work has a timeline to make it in quickly.

[steveharter]

One potential path to reduce size as new features (and converters) are added is to initialize JsonSerializerOptions with no converters and then add only the converters necessary for the given application and scenarios. @layomia recently added the source-gen \ trimming work that does this but it could be extended and used without source-gen:

internal class MyCustomContext : JsonSerializerContext
{
    public MyCustomContext(JsonSerializerOptions options) : base(options) { }
    // Also possible to cache\expose the JsonTypeInfos here...
}

JsonSerializerOptions options = new JsonSerializerOptions;
options.Converters.Add(JsonConverters.String);
options.Converters.Add(JsonConverters.Int32);
options.Converters.Add(JsonConverters.JsonNodeConverterFactory);
// etc

var context = new MyCustomContext(options);
JsonNode node = ...
JsonSerializer.Serialize(node, context);

[SamMonoRT]

Assigning to @layomia for tracking based on additional work building over the JSON SourceGenerator work

[layomia]

Following up on offline discussions on email, I'm noting on this issue that the path to reducing the regression here will not be about Blazor fully adopting the JSON source generator internally and in the default template (dotnet/aspnetcore#31877). Size is important for Blazor, but it was discussed that the generator should focus on trim safety (already supported), and improve (de)serialization throughput (in progress with #51945).

For mitigating the size regression here, this issue will instead focus on internal System.Text.Json changes to reduce the assembly size when source gen is not used:

• Possible linker removal JsonNode (+ ancillary classes) Possible linker removal of JsonDocument and JsonNode (+ ancillary classes) to save 35% of STJ.dll size #51756
• Evaluate existing converters for uncommonly-used collections using late-bound references to reduce assembly dependency size
• Remove System.Text.Json's DynamicDependencies on Collections.Immutable Remove System.Text.Json's DynamicDependencies on Collections.Immutable #53256
• Consider linker switch to trim out ref emit code and always use normal reflection instead (JsonSerializerOptions.MemberAccessorStrategy shouldn't use Reflection.Emit when IsDynamicCodeCompiled is false #38693). We've estimated ~16K compressed savings with this approach.

cc @SamMonoRT @CoffeeFlux @eerhardt @steveharter @ericstj @SteveSandersonMS @pranavkm @jkotas

[lewing]

Is there any remaining .NET6 work here?

[layomia]

I believe there's no work left here for 6.0 given the above plan #51311 (comment). cc @eerhardt

[eiriktsarpalis]

I think we can close this issue now?