Remove 6 IntPtr fields from SocketAsyncEventArgs on Windows#22170
Conversation
|
@stephentoub any noticeable impact on run-time perf? (From the changes I would't think so but worth trying out the Perf tests.) |
| pMessage->addressLength = (uint)_socketAddress.Size; | ||
| pMessage->buffers = _ptrWSARecvMsgWSABufferArray; | ||
| if (_buffer != null) | ||
| fixed (void* ptrWSARecvMsgWSABufferArray = &wsaRecvMsgWSABufferArray[0]) |
There was a problem hiding this comment.
Why is this better than UnsafeAddrOfPinnedArrayElement?
There was a problem hiding this comment.
It's a bit faster, at least in the tests I did. I tried this, UnsafeAddrOfPinnedArrayElement, GCHandle.AddrOfPinnedObject, etc., and this won so I went with it.
There was a problem hiding this comment.
UnsafeAddrOfPinnedArrayElement,GCHandle.AddrOfPinnedObject
All these methods have argument validation, etc. that makes them slower than necessary.
pMessage->buffers = (IntPtr)Unsafe.AsPointer(ref wsaRecvMsgWSABufferArray[0]) should be the fastest way to do this (a few instructions better than the dummy fixed statement), but it would require adding a dependency on S.R.CS.Unsafe.
No. For the most part the used fields aren't on code paths exercised by the perf tests, which are mainly focused on Connect/Accept/Send/Receive. |
…ields Remove 6 IntPtr fields from SocketAsyncEventArgs on Windows Commit migrated from dotnet/corefx@1fff38f
5 participants
In the Windows implementation of SocketAsyncEventArgs, we're currently storing in six IntPtr fields values that we can efficiently recreate at run time, and by removing the fields, we save 48 bytes per SocketAsyncEventArgs instance (on 64-bit). Unfortunately SocketAsyncEventArgs is currently quite large, so that's "only" 7%, but it's a good start.
cc: @geoffkizer, @davidsh, @CIPop