I have done some benchmarking of this on Linux. The result vary between runs as it's highly system dependent but I can see some useful result from that:

• file to file - this seems pretty much the same as both use copy_file_range
• file to socket - this one shows the biggest improvement as sendfile is clearly faster here. I actually started without this change 682f12b and saw significant slow down because it was using fallback. But after fixing that and verifying that sendfile is used, I saw a significant improvement so this really works.
• socket to socket and socket to file - both of those might cause slight slow down (overhead) for small copy but it seems improving larger copying where splice pipe overhead disappear. There is also significant reduction of syscalls so this seems like an improvement as well.

So this seems good in terms of Linux perf which probably matter most. We should look after some follow ups to improve FreeBSD, MacOS and other unix variant. The sendfile works a bit differently for partial writes (think it blocks there but I made some changes so it is only used for real socket so it should be fine). there so it needs more testing but I think it can be a follow up PR.

I should also note that the pipe check is there for future use - that pipe flag is only supported on Win but if we supported pipes more on Linux, we could potentially make use of that and it would limit some overhead for splice.

@devnexen Please could you review it.

I ll do a deeper dive sometime next week but here some quick findings.