Change System.Net.WebSockets contract for WebSocketReceiveResult

[benaadams]

Follow up from "Resuable WebSocketReceiveResult" dotnet/corefx#4520

At the moment is WebSocketReceiveResult is a read only POCO type that as a class must be garbage collected on every single socket message; probably gen0; but still bad for high speed websockets.

I can see two approaches to address this:

1. Change the setters to protected, which opens up a possibility for types derived from System.Net.WebSockets.WebSocket to reuse the result object using a derived WebSocketReceiveResult type.
2. Change type from class to struct.

Either approach halves the number of allocations, second is safer but allocates more memory. (Though ValueTask returns could change this)

[benaadams]

cc: @davidsh

[davidfowl]

I always wondered why it wasn't a struct. Does anyone derive from this type?

[benaadams]

While breaking contracts might be useful if it was a struct and ReceiveAsync returned a ValueTask<WebSocketReceiveResult> instead...

(perhaps a rookie question)
How would changing class to struct makes data reusable?

[davidsh]

cc: @CIPop @pgavlin @SidharthNabar @bartonjs @terrajobst

[benaadams]

@jasonwilliams200OK it doesn't; it means the GC doesn't allocate an object handle for it which it then needs to check and clean up.

[CIPop]

@benaadams Thanks for your input!
Could you share any perf numbers observed in your real-world scenario when you make this change?

The reasons we can't change the contract is portability between Desktop and CoreCLR. We would consider adding another overload if the perf increase in a real-world scenario justifies it.

At the same time, please note that we are not yet done with the WebSockets implementation and porting all tests. To avoid destabilizing the implementation, this work will be postponed until we've implemented and tested the existing contract.

I always wondered why it wasn't a struct. Does anyone derive from this type?

@davidfowl Nothing derives or should be deriving from this type. I don't know/understand the original design decision either.

How would changing class to struct makes data reusable?

@jasonwilliams200OK See https://msdn.microsoft.com/en-us/library/ms173109.aspx for clarification. The short answer is that struct is a value-type and will not be managed by GC.

@benaadams, @CIPop thanks for the answers and the link. The answers at http://stackoverflow.com/q/2146434 by @jskeet and @ericlippert further clarified on value-type datastructures' instances are GC-agnostic and instance they are virtually popped out by reverting the CPU stack pointer back when IP goes out of scope (on function return for example).

[benaadams]

@jasonwilliams200OK unless they are instance members of a class; but the GC still doesn't pay attention to them - same behaviour as adding an int to a class though probably larger.

[benaadams]

@CIPop this is a perfview of our current allocators and WebSocketReceiveResult is about 17th on the list

[CIPop]

/cc: @himadrisarkar

Thanks @benaadams!

[benaadams]

After some optimizations and upgrading to aspnet Websocket 0.2.0 which shares corefx's impl

WebSocketReceiveResult and Task<WebSocketReceiveResult> are items 3 and 5 on our top allocated items (on non-ssl):