eg I found that I mustnt use fputc(fgetc(),fp)
to copy a large subset of a file just by direct observation
that it was taking much longer than it should:
I didnt know it was because there was an entire task-switch overhead
involved, but I knew it was much too slow,
using fopen is never a good idea if you want the copy performance. Then you make it worse with the overhead of making read and write calls for every single character. For best speed use no buffering (Open/Read/Write instead of fopen/fread/fwrite) and then read and write in large chunks that are a power of 2 (32k is a good small number ). When copying between different devices you can use multiple threads or asynchronous reads/writes so both devices are busy all the time. When copying on one device it's better to use a much larger buffer and only either read or write.
But unless you understand why you should do these things then it's just cargo cult programming.
However I had to knock up a one off program that had to split some files up and I used fputc/fgetc because it was quicker to code & the run time was a fraction of how long it took to code. Making compromises is the art of being a commercial programmer.
