add binary xml version to xml benchmarks #2557
Conversation
|
@StephenMolloy could you review? I'm not familiar with the API. |
| [Benchmark(Description = nameof(XmlDictionaryReader))] | ||
| public T DataContractSerializer_BinaryXml_() | ||
| { | ||
| ((IXmlBinaryReaderInitializer)xmlDictionaryReader).SetInput(memoryBytes, 0, memoryBytes.Length, null, XmlDictionaryReaderQuotas.Max, null, null); |
There was a problem hiding this comment.
Consider using [IterationSetup] for this step. (https://github.com/dotnet/performance/blob/main/docs/microbenchmark-design-guidelines.md#iterationsetup)
There was a problem hiding this comment.
I did so earlier for my own benchmarks but that was not very successful for this case.
I think it might be fair game to benchmark with the SetInput call since that is needed for any real world scenario (corewcf , OpenRiaServices etc) where you want to read one "xml document" at a time but pool readers/writers for reuse.
When using iterationsetup the method itself should be quite long running (i think either above guidance or some other guidance says 100ms+) so it must process a lot of objects.
However I have prepared an alternative version using OperationsPerInvoke at https://github.com/Daniel-Svensson/dotnet_performance/tree/remote_setoutput with commit
128fcdf if you rather want that one. It will instead read N (100 but I am open for any value) similar objects inside a single "root" element. So the overhead will go from <= 1% to maybe 0,01% of the execution time, but will no longer match the other benchmarks.
There was a problem hiding this comment.
@danmoseley Do you prefer the current version which mimics the end user scenario or should the binary xml version of the benchmarks serialize many more objects than the other benchmark versions ?
unless the ci-failures are related to the changes here I think this is ready for possible merge.
There was a problem hiding this comment.
This is @StephenMolloy area to answer..
|
@StephenMolloy, do you think the current version looks fine and is ready to merge? Most of your comments are fixed, except iterationsetup (see comment above on why). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
As suggested by @danmoseley in dotnet/runtime#73336 (comment)
This should help protect performance for binary xml scenarios such as corewcf.
Apart from PR mentioned above this should also cover the changes in
And generally make Datacontractserializer changes easier to spot since binary xml has lower overhead than text based version