Improve allocations in ReflectionXmlSerializationWriter when serializing primitive types

[TrayanZapryanov]

Follow up of #76436
More primitives are serialized into char buffer and then written into writer, instead of serialized to string.

Next step is to use similar methods/approach in XmlSerializationWriterILGen.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TrayanZapryanov]

@mconnew, @StephenMolloy
Do you see any value in these changes?
They introduce fast path serializing primitive types as elements/attributes. Which is supposed to succeed, but if not - then the old logic stays.
If I can read code correctly XmlSerializationWriterILGen is to produce code similar to the ReflectionXmlSerializationWriter, just skipping reflection part.
So the code that we embed into reflectionwriter should be easily portable int ILGen one.
Once similar changes are in XmlSerializationWriterILGen code, then I see the biggest benefit of reducing allocations of all primitive types...

[TrayanZapryanov]

This is optional - can be private and then we just have another buffer here.

[Wraith2]

This feels a bit weird. Are there other places in ref assemblies where protected fields are exposed?

[StephenMolloy]

@mconnew, @StephenMolloy Do you see any value in these changes? They introduce fast path serializing primitive types as elements/attributes. Which is supposed to succeed, but if not - then the old logic stays. If I can read code correctly XmlSerializationWriterILGen is to produce code similar to the ReflectionXmlSerializationWriter, just skipping reflection part. So the code that we embed into reflectionwriter should be easily portable int ILGen one. Once similar changes are in XmlSerializationWriterILGen code, then I see the biggest benefit of reducing allocations of all primitive types...

It will be a little while before we get a chance to review these changes. But assuming they are like the last PR, I would anticipate the improvements are welcome. A couple of notes:

1. Use private fields for the buffer. We don't want to find ourselves in a situation where pre-generated serializers start relying on the protected field that doesn't exist on all potential runtimes.
2. Our plan is to try to migrate away from the ILGen serializer implementation. The code is tricky and messy in every way. I'd stay away from it. We are unlikely to accept any PR's in that area.

[TrayanZapryanov]

@StephenMolloy Fair enough.
I also think that IlGen is not for everyone and will close this PR if this is the direction.
Can you share a bit your plans for xml serialization, so I can check if there's something that I can help?

[StephenMolloy]

@TrayanZapryanov - Did I miss something? This draft is for the reflection-based serializer, which is the direction we do want to move. My second point above was responding to

the code that we embed into reflectionwriter should be easily portable int ILGen one. Once similar changes are in XmlSerializationWriterILGen code...

I didn't want you or anybody else to go down that ILGen road since it likely doesn't play a big part in the future.

[TrayanZapryanov]

@StephenMolloy Sorry I somehow misread your statement and decided that you don't like PRs for Xml serialization and have plans to replace it with something else.. Maybe something connected with source generators...
I will check again this draft and try to tune it, so don't worry for the review. Do it when you have time.

[ghost]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.