Repository navigation
Default implementations on IXmlReadHandler are a footgun #3
Description
Activity
the .NET runtime will need to box the implementing
structto call the default implementation provided by the interface (the type ofthiswithin the interface is a reference type)But
IXmlReadHandleris used through generics in TurboXml and default implementation seems to be correctly inlined without boxing (For example here), and none of the default implementations are using this.Do you have an example where you would get this boxing with TurboXml?
I avoid them in general. There's definitely a box in the IL sense and whether the JIT can optimize the box out depends on many things (e.g. if the struct is generic over a reference type, it would probably not optimize it out, see e.g. dotnet/runtime#39419).
Reacted by Alexandre MutelGot it. I'll change this in a breaking version.
The underlying optimization issue has been fixed in .NET 11 by dotnet/runtime#128702 (the first version with the optimization would be .NET 11 preview 7).
This is a great library! I have a need to parse 100+ MB of XML, most of which are various IDs that I never need to surface as a
System.String, so I almost wrote my own XML parser, but I'm glad I didn't need to.One minor annoyance are the default implementations on
IXmlReadHandler. VS doesn't seem to offer the option to "Implement interface explicitly", so I had to list/implement each of these myself. If any of them is left unimplemented, the .NET runtime will need to box the implementingstructto call the default implementation provided by the interface (the type ofthiswithin the interface is a reference type). I'd honestly get rid of the default implementation, they are a footgun for perf-sensitive code where the interface is expected to be implemented on a struct. Maybe leave the one for the error case.