Reduce the memory footprint of ManagedWebSocket #52022
Conversation
…ill instead of custom instance of RandomNumberGenerator.
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsWhile working on the websocket compression I noticed two things but decided to leave them after the feature was completed:
This reduced the memory footprint of a websocket without compression state from 752 bytes to 552 bytes. //cc @CarnaViire @scalablecory
|
|
FYI: CI failures are ongoing infra issue. I will rerun checks after it's fixed |
|
@CarnaViire the failing tests seem unrelated. Let me know if anything else is needed. |
|
@zlatanov sorry for delaying on the rerun 😔 I've triggered it now |
While working on the websocket compression I noticed two things but decided to leave them after the feature was completed:
RandomNumberGenerator, which could be replaced withRandomNumberGenerator.Fill.ManagedWebSocketclass was creatingCancellationTokenSourcebut never really used the cancellation part. Since continuations fromCancellationTokenSource.Cancelare executed synchronously, the cancellation source could be replaced with a method.This reduced the memory footprint of a websocket without compression enabled from 752 bytes to 552 bytes.
//cc @CarnaViire @scalablecory