It looks like this is using multiple threads to copy files. That's fine for NVMe which tends to achieve more throughput with higher queue depths. But it will degrade performance when copying large files on spinning rust.
On a SATA hard drive using ext4, I copied a directory with a large hierarchy of file and 216MB overall. After 2 warm-ups, I launch this simple benchmark.
time cp -r moodle X
13.76s s (0.06s u + 2.44s k) 18% CPU
time fcp-0.1.0-x86_64-unknown-linux-gnu moodle X
46.12s s (0.15s u + 2.47s k) 3% CPU
This does not mean the fcp is bad or not performant. But it some cases, it can be 3x slower.
One copy operation is the little files and deep hierarchy. The other copy operation is just a big file. Both operations start at same time and use the same tool.
I'm curious what cp and fcp do to the cache as they operate.
Does it mean you are doing this operation enough times to trick the kernel to cache everything in RAM? Or you run it 3 times and chose the fastest timings?
I think there are sometimes arguments to be made that, for the user, that is run time. When using benchmarks to compare programs like this, though, I think isolating the "actual" (i.e. useful) program execution is productive.
Second run: fcp binary is cached by the OS in RAM so it starts up faster.
Third run: just to make sure :)
This is just one of the things of a type of cache that can be warmed up.
I learned this the hard way when dismantling and abusing a dead HDD. Had to vacuum all the tiny shards from the floor.
Great old video. Thanks for sharing. Terrifying goose though.