-pipe
Use pipes rather than temporary files for communication
between the various stages of compilation. This fails
to work on some systems where the assembler is unable to
read from a pipe; but the GNU assembler has no trouble.
So presumably this is a compile speed optimization. What sort of an improvement does it actually provide? I tested this by compiling LLVM on my desktop machine both with and without the -pipe command line argument. Without it I got the following time:
ninja 14770,75s user 799,50s system 575% cpu 45:04,98 total
Adding the argument produced the following timing:
ninja 14874,41s user 791,95s system 584% cpu 44:41,22 total
This is an improvement of less than one percent. Given that I was using my machine for other things at the same time, the difference is most likely statistically insignificant.
This argument may have been needed in the ye olden times of supporting tens of broken commercial unixes. Nowadays the only platform where this might make a difference is Windows, given that its file system is a lot slower than Linux's. But is its pipe implementation any faster? I don't know, and I'll let other people measure that.
The "hindsight is perfect" design lesson to be learned
Looking at this now, it is fairly easy to see that this command line option should not exist. Punting the responsibility of knowing whether files or pipes are faster (or even work) on any given platform to the user is poor usability. Most people don't know that and performance characteristics of operating systems change over time. Instead this should be handled inside the compiler with logic roughly like the following:
if(assembler_supports_pipes(...) &&
pipes_are_faster_on_this_platform(...)) {
communicate_with_pipes();
} else {
communicate_with_files();
}
Your proposal would fail on the simple use case mentioned in the manpage: it's usage depends on the assembler, not necessarily on the platform, in which case the usage of conditionals might or might not be practical.
ReplyDelete