Potential size reduction opportunities in System.Text.Json NativeAOT

[eiriktsarpalis]

The PR in #80755 attempted to reduce the size of System.Text.Json components in trimmed NativeAOT binaries. The per-namespace breakdown in #80755 (comment) shows that there might be opportunity to further reduce application size in the System.Text.Json.Serialization.Metadata namespace, which currently occupies approximately 600k in the Golidlocks app. More specifically, the metadata layer introduces overhead in a couple of ways:

1. Using separate JsonTypeInfo<T> implementations for source gen and reflection. This segregation largely exists for historical reasons and it could be removed, decoupling JsonTypeInfo<T> metadata from contract resolution behavior.
2. The source generator sets JsonTypeInfo metadata using the JsonMetadataServices APIs as a proxy. This happens because the source generator predates the public APIs on JsonTypeInfo itself. The proxy API introduces a number of generic classes such as JsonCollectionInfoValues<T>, JsonObjectInfoValues<T> and JsonPropertyInfoValues<T>. All these types could be trimmed if we updated the source generator to call into the JsonTypeInfo APIs directly. Note that this is currently blocked by Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944, the only remaining configuration point available in JsonMetadataServices but not yet present in JsonTypeInfo<T>.

cc @eerhardt @krwq @layomia

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The PR in #80755 attempted to reduce the size of System.Text.Json components in trimmed NativeAOT binaries. The per-namespace breakdown in #80755 (comment) shows that there might be opportunity to further reduce application size in the System.Text.Json.Serialization.Metadata namespace. More specifically, the metadata layer introduces overhead in a couple of ways:

1. Using separate JsonTypeInfo<T> implementations for source gen and reflection. This segregation largely exists for historical reasons and it could be removed, decoupling JsonTypeInfo<T> metadata from contract resolution behavior.
2. The source generator sets JsonTypeInfo metadata using the JsonMetadataServices APIs as a proxy. This happens because the source generator predates the public APIs on JsonTypeInfo itself. The proxy API introduces a number of generic classes such as JsonCollectionInfoValues<T>, JsonObjectInfoValues<T> and JsonPropertyInfoValues<T>. All these types could be trimmed if we updated the source generator to call into the JsonTypeInfo APIs directly. Note that this is currently blocked by Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944, the only remaining configuration point available in JsonMetadataServices but not yet present in JsonTypeInfo<T>.

Author:	eiriktsarpalis
Assignees:	eiriktsarpalis
Labels:	area-System.Text.Json, untriaged
Milestone:	-

[ghost]

Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The PR in #80755 attempted to reduce the size of System.Text.Json components in trimmed NativeAOT binaries. The per-namespace breakdown in #80755 (comment) shows that there might be opportunity to further reduce application size in the System.Text.Json.Serialization.Metadata namespace. More specifically, the metadata layer introduces overhead in a couple of ways:

1. Using separate JsonTypeInfo<T> implementations for source gen and reflection. This segregation largely exists for historical reasons and it could be removed, decoupling JsonTypeInfo<T> metadata from contract resolution behavior.
2. The source generator sets JsonTypeInfo metadata using the JsonMetadataServices APIs as a proxy. This happens because the source generator predates the public APIs on JsonTypeInfo itself. The proxy API introduces a number of generic classes such as JsonCollectionInfoValues<T>, JsonObjectInfoValues<T> and JsonPropertyInfoValues<T>. All these types could be trimmed if we updated the source generator to call into the JsonTypeInfo APIs directly. Note that this is currently blocked by Add support for parameterized constructors in System.Text.Json contract customization (converters) #71944, the only remaining configuration point available in JsonMetadataServices but not yet present in JsonTypeInfo<T>.

Author:	eiriktsarpalis
Assignees:	-
Labels:	area-System.Text.Json, untriaged, size-reduction
Milestone:	Future

[krwq]

Shouldn't the split into source-gen/reflection help eventually? I'd assume if you use source-gen all ReflectionJsonTypeInfo should get trimmed away (and reverse). Should we strive into that actually happening if it's not currently?

[krwq]

Other option we can move all the reflection logic to DefaultJsonTypeInfoResolver and keep JsonTypeInfo clean. That should achieve same effect and might actually be easier to achieve

[eiriktsarpalis]

Shouldn't the split into source-gen/reflection help eventually? I'd assume if you use source-gen all ReflectionJsonTypeInfo should get trimmed away (and reverse). Should we strive into that actually happening if it's not currently?

The derived types aren't necessary and because they are generic they contribute to a linear increase of application size in NativeAOT apps. There should eventually be one sealed JsonTypeInfo<T> class that each resolver populates independently.