Slice conn with faster write and faster read about websocket HOT 6 CLOSED

Also see golang/go#18152 (comment)

I don't think the writer allocation for every write is a big deal.

from websocket.

The major issue I see with the writer is you have to close it so every data msg greater than the buffer size of 4096 bytes will be sent with three writes on the conn instead of two.

from websocket.

I think the move is to remove the allocations altogether and just use a value type on the Conn and put the read/write state there.

from websocket.

That definitely removes the need for the Read method but the Write method makes sense to avoid the extra fin frame being written but I doubt anyone will ever notice that with the overhead of everything else in the stack so I'm good with the API as is.

from websocket.

Definitely should benchmark this at some point with big payloads.

from websocket.

So I benched this and it turns out there is no latency difference but the extra syscall adds 5000ns which is 5µs which isn't really that much at all so I don't think its a big deal. Can revisit if someone complains about performance but this isn't really going to show up if you're writing messages larger than 4096 bytes and I can always increase the buffer size to something like 32kb which would be good enough for pretty much everyone. I don't want to add a special case API unless absolutely necessary.

from websocket.