Implement zero copy writes for the WebSocket writer

[bdraco]

Implement zero copy writes for the WebSocket writer
closes #9633

python/cpython#91166 made writelines zero copy for Python 3.12+. For older versions it will still join the bytes

Would like another set of 👀 on this to make sure it makes sense.

[codspeed-hq]

CodSpeed Performance Report

Merging #9634 will degrade performances by 16.77%

_{Comparing zeroconf_writes (95efb03) with master (5b654d5)}

Summary

⚡ 1 improvements
❌ 1 regressions
✅ 11 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	master	zeroconf_writes	Change
❌	test_one_thousand_large_round_trip_websocket_text_messages[pyloop]	22.8 ms	27.4 ms	-16.77%
⚡	test_send_one_hundred_websocket_text_messages_with_mask[pyloop]	807.9 µs	745.5 µs	+8.36%

[codecov]

❌ 6 Tests Failed:

Tests completed	Failed	Passed	Skipped
3378	6	3372	24

View the top 3 failed tests by shortest run time

tests.test_client_ws_functional test_heartbeat_connection_closed[pyloop]

Stack Traces | 0.397s run time

No failure message available

tests.test_client_ws_functional test_heartbeat[pyloop]

Stack Traces | 10.1s run time

No failure message available

tests.test_client_ws_functional test_heartbeat_no_pong_concurrent_receive[pyloop]

Stack Traces | 10.2s run time

No failure message available

To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard

[bdraco]

Benchmarks barely show any improvement. I think the message payload would have to be rather large for it to matter.

We don't have any benchmarks for that

[bdraco]

Still probably not a good benchmark. Will need to extend the round trip WebSocket benchmark to have another one that sends large messages to really get an idea of how it will perform

[bdraco]

Its looking like this is worse because the reader is more fragmented. Probably worth optimizing the reading of larger messages before this would make sense

[bdraco]

I think part of the reason it’s slower is the protocol gets paused. Everything backs up against the drain waiter in the writer anyways so maybe we need a queue that doesn’t pause writes in two places

Nevermind. I was misremembering. It’s reads that get paused which makes more sense

[bdraco]

Anyways. Let’s see what the profile looks like with now with all the memcpy reduction optimizations

[bdraco]

We still end up with more fragmentation somehow.

Probably need to work on the reader some more

[bdraco]

need to look at this with syscalls