Performance. This is an I/O-bound process; the main influence in performance is the buffer size: the tool reads a chunk from the source, writes the chunk

Performance. This is an I/O-bound process; the main influence in performance is the buffer size: the tool reads a chunk from the source, writes the chunk to the destination, repeats. If the chunk is too small, the computer spends its time switching between tasks. If the chunk is too large, the read and write operations can't be parallelized. The optimal chunk size on a PC is typically around a few megabytes but this is obviously very dependent on the OS, on the hardware, and on what else the computer is doing. I made benchmarks for hard disk to hard disk copies a while ago, on Linux, which showed that for copies within the same disk, dd with a large buffer size has the advantage, but for cross-disk copies, cat won over any dd buffer size. As a meta comment, it has been a shocking revelation in my career that the difference between "get it work" engineers and "make it right, make it fast"[3] has been this kind of low level knowledge. At least in my context, the majority of the bugs that have come up in the past while haven't been because someone didn't know how to concatenate 2 strings or even that many off by 1 errors. They have been things like not knowing the difference between theoretical TCP models and how their actually implemented on the OS in a high throughput environment (see TIME_WAIT[1] if you're curious), or understanding misorder of operations in distributed computing[2]. [1]: https://9oelm.github.io/2018-05-06--Listening,-Established,-Close_wait-and-Time_wait-in-netstat/ https://9oelm.github.io/2018-05-06--Listening,-Established,-... [2]: http://book.mixu.net/distsys/ http://book.mixu.net/distsys/ [3]: https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast