Re:Code Inflation [pdf]
by function_seven on Friday April 17, 2015 @11:41PM
(#9398234)
I just repeated your test, but got opposite results:
$ time /usr/bin/true
real 0m0.003s
user 0m0.001s
sys 0m0.002s
$ time /usr/bin/truth
real 0m0.001s
user 0m0.000s
sys 0m0.001s
I can't imagine for the life of me how an empty file could perform worse than an actual binary, but there's gotta be a reason.If you're relying on an empty binary, or exit 0; instead of an actual binary you have to execute a shell process to evaluate it. The binary doesn't need to load a shell, it can just do a bit of setup, then make a single exit 0 system call.
Re:Code Inflation [pdf]
by function_seven on Saturday April 18, 2015 @05:04PM
(#9401030)
Thank you. That makes sense. So basically the empty file is seen by the shell as a "script" that has to be evaluated, so a separate shell process is spun up to handle it? And the difference between my output and the parent's has to do with some difference in our environments?
Re:Code Inflation [pdf]
by logicallee on Saturday April 18, 2015 @08:35AM
(#9399216)
this is what happens when we aren't allowed to use p values anymore :)
https://www.sciencebasedmedicine.org/psychology-journal-bans...
The default p is p = 0.5, so I have no trouble accepting both your conclusion and your parent's :)
seriously though, this is why we use significance testing in real fields, like computer science...
I created an empty file, a la the original true, named truth and placed it at the beginning of my $PATH.
I then realized that since true is a builtin, I'd need to call the true binary with its full path. I'd hate to give one an unfair advantage by having to search the path vs being called by name. So.... Clearly my 2KB true binary is superior to an empty file. The builtin (obviously) outperforms both, by at least one order of magnitude (estimated).This post is not intended to be a serious performance comparison.