You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Azure SDK ecosystem errors are serialized by the server as XML and parsed into XDocument, In the stack trace below the string message is wrapped into a TextReader which is then passed down to the XmlTextReaderImpl where a buffer is allocated. Even in the case when InitTextReaderInput is called with a string source instead of a TextReader the entire string is copied to a new char[] with a (char)0 ending.
It seems that if span can be leveraged that significant performance could be gained. If no one sees a clear path for this, no worries just want to make sure there isn't any low hanging fruit here.
Configuration
Which version of .NET is the code running on? 5.0.9
What OS version, and what distro if applicable? Windows Server 2019
What is the architecture (x64, x86, ARM, ARM64)? x64
I initially tried altering the following by verifying that 0 ending array is required and making it a direct copy of the string does cause two unit tests to break.
Tagging subscribers to this area: @dotnet/area-system-xml
See info in area-owners.md if you want to be subscribed.
Issue Details
Description
In the Azure SDK ecosystem errors are serialized by the server as XML and parsed into XDocument, In the stack trace below the string message is wrapped into a TextReader which is then passed down to the XmlTextReaderImpl where a buffer is allocated. Even in the case when InitTextReaderInput is called with a string source instead of a TextReader the entire string is copied to a new char[] with a (char)0 ending.
It seems that if span can be leveraged that significant performance could be gained. If no one sees a clear path for this, no worries just want to make sure there isn't any low hanging fruit here.
Configuration
Which version of .NET is the code running on? 5.0.9
What OS version, and what distro if applicable? Windows Server 2019
What is the architecture (x64, x86, ARM, ARM64)? x64
I initially tried altering the following by verifying that 0 ending array is required and making it a direct copy of the string does cause two unit tests to break.
Hi @johnthcall, we'd be happy to consider a PR that adds spanification improvements to the XmlTextReader implementation. Would it be possible to also share benchmarks that demonstrate the perf improvements?
Description
In the Azure SDK ecosystem errors are serialized by the server as XML and parsed into XDocument, In the stack trace below the string message is wrapped into a TextReader which is then passed down to the XmlTextReaderImpl where a buffer is allocated. Even in the case when InitTextReaderInput is called with a string source instead of a TextReader the entire string is copied to a new char[] with a (char)0 ending.
It seems that if span can be leveraged that significant performance could be gained. If no one sees a clear path for this, no worries just want to make sure there isn't any low hanging fruit here.
Configuration
Data
clr.dll!JIT_NewArr1
System.Xml.ni.dll!System.Xml.XmlTextReaderImpl.InitTextReaderInput(System.String, System.Uri, System.IO.TextReader)$##6000B97
System.Xml.ni.dll!System.Xml.XmlTextReaderImpl.FinishInitTextReader()$##6000B10
System.Xml.ni.dll!System.Xml.XmlReaderSettings.CreateReader(System.IO.TextReader, System.String, System.Xml.XmlParserContext)$##6000A31
System.Xml.Linq.ni.dll!System.Xml.Linq.XDocument.Parse(System.String, System.Xml.Linq.LoadOptions)$##60001A0
Azure.Core.Pipeline.StorageClientDiagnostics!ExtractFailureContent
Analysis
I initially tried altering the following by verifying that 0 ending array is required and making it a direct copy of the string does cause two unit tests to break.
runtime/src/libraries/System.Private.Xml/src/System/Xml/Core/XmlTextReaderImpl.cs
Lines 3058 to 3061 in 918aaec
If the 0 ending array is strictly required then a copy of the full array will always be required.
I'm happy to contribute changes here but don't know if it is feasible or the best place to start.
The text was updated successfully, but these errors were encountered: