-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Optimize SqlClient tds state to remove handle boxing #34044
Conversation
…id boxing of IntPtr in native mode
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserSafeHandles.cs
Outdated
Show resolved
Hide resolved
Fixed up merge conflicts from the other optimizing PR merged yesterday. |
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObject.cs
Outdated
Show resolved
Hide resolved
@dotnet test OSX x64 Debug Build please |
src/System.Data.SqlClient/src/System/Data/SqlClient/PacketHandle.Windows.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/PacketHandle.Windows.cs
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/PacketHandle.Windows.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/SessionHandle.Windows.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/SessionHandle.Windows.cs
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/SessionHandle.Windows.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObjectFactory.Windows.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObjectNative.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObjectNative.cs
Show resolved
Hide resolved
@Wraith2 can you update the description of the PR since you got rid of |
remove unused packethandle variable in IsConnectionAlive remove identidal overridden implementations of EmptyReadHandle
Description updated and everything addressed. |
Getting test failures about mismatched packets, i'll push and let you know when it's passing. |
@Wraith2 Do you happen to have the test failure link ? |
It's a manual test, stack trace is:
|
OK. Keep me posted. |
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObject.cs
Outdated
Show resolved
Hide resolved
src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObjectFactory.Windows.cs
Outdated
Show resolved
Hide resolved
…kets in implementations define IsValidPacket implementations more stringently with type checks
@Wraith2 Just to be sure, is this ready for review again? Can the WIP be removed? |
internal override bool IsValidPacket(PacketHandle packet) => packet.ManagedPacket?.IsInvalid ?? false; | ||
internal override bool IsValidPacket(PacketHandle packet) | ||
{ | ||
return ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Why would we run into the this packet type not being ManagedPacketType? Can we solve this problem where it begins? Rather than having the check here about the type of packet being valid?
There should be no reason that IsValidPacket in TdsParserStateObjectManaged should get a native packet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you use PacketHandle packet = default'
you'll get type 0 which is not managed or native, it's just unknown. The answer is that you should never use default
but I can't make the compiler enforce that so this is the next best thing. If you do use default you will get a fault during testing.
It isn't possible to get managed and native mixed up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, I think this method deserves a Debug.Assert as well just the way you added in TdsParserStateObjectNative.IsVaildPacket
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Ready to review and test, thanks for the help and patience. |
@dotnet-bot Test Linux x64 Release Build
|
@dotnet-bot Test Linux-musl x64 Debug Build |
@dotnet-bot Test this |
Ready to merge once the CI is green. |
@dotnet-bot Test Packaging All Configurations x64 Debug Build
|
@dotnet-bot Test Linux arm Release Build |
@dotnetbo test Tizen armel Debug Build please |
…4044) * change TdsParserStateObject to pass packets using a ref struct to avoid boxing of IntPtr in native mode * add project define for FEATURE_INTEROPSNI on windows non uap builds * update interop to use SniPacketHandle type name * rename SNIPacketHandle to SNIPacket * split PacketHandle and SessionHandle into separate files and implementations * add comments to PacketHandle and SessionHandle remove unused packethandle variable in IsConnectionAlive remove identidal overridden implementations of EmptyReadHandle * move lazy bool into debug region * re-add EmptyReadPackt and provide correctly types valid but empty packets in implementations define IsValidPacket implementations more stringently with type checks * change implementation switch name to make more sense * add packet type assertion in IsValiePacket Commit migrated from dotnet/corefx@d3d8c74
These changes remove constant boxing of session and packet IntPtr when using the native implementation of TdsParserStateObject (native is used in windows non-uap builds) which improves memory performance. Making these changes also allows assertion of the handle types in debug builds which adds safety and testability.
I have used ref structs to ensure that the types can only be used to pass information through the abstract methods that define the interface between the core parser logic and the native/managed specific elements, these handles can never be accidentally stored or take part in async activity. There are separate unnix and windows implementations of these types to handle the differences in members and simplify development using them.
Performance profiling results were posted in #33155 and show approximately ~13% speed increase on small write performance and lower GC frequency.
This PR was split from #33155 for easier review.
/cc @keeratsingh @afsanehr @saurabh500 @David-Engel