4 ms·

Depends on the design goals. If you want secure code, you'll make it readable. Here's true(1): : A single "noop" in a 755 file. A C true would be: https://

Depends on the design goals. If you want secure code, you'll make it readable. Here's true(1): : A single "noop" in a 755 file. A C true would be: https://cvsweb.openbsd.org/src/usr.bin/true/true.c?rev=1.1&content-type=text/x-cvsweb-markup https://cvsweb.openbsd.org/src/usr.bin/true/true.c?rev=1.1&c... Here's a much faster true(1) if you need it: https://github.com/coreutils/coreutils/blob/master/src/true.c https://github.com/coreutils/coreutils/blob/master/src/true....

iainmerrick 8y ago
I did say “one of the goals”. I don’t see how those examples are relevant. Why would that last one be faster? I agree that the OpenBSD code here is good, no more and no less than needed. I assumed the grandparent was referring to cases where an O(n) algorithm is used where it might be O(log n) or O(1) with just a little more effort. It’s a tradeoff, sure, and in some cases linear searches can work surprisingly well, but in general I think this kind of thing should always be considered in good code. Micro-optimizations like inline assembly for inner loops may or may not be a good idea, depending on the application. All else being equal, I’d certainly agree that good clean code would not use assembly.
josefx 8y ago
How is the coreutils true faster? I would expect the openbsd true to be the fastest, it doesn't need to spawn a subshell and it doesn't do more than the posix specification requires (afaik --help/--version should be ignored).
- moviuro 8y ago
  Experience shows it's faster. It's just weird, but it's like that. time { for i in $(seq 1 10000); do /path/to/true; done; }
  - iainmerrick 8y ago
    What are you comparing against what there? Two C executables with the same compiler flags on the same OS?
hultner 8y ago
Is the gnu-coreutils true much faster? I have a hard time seeing how return 0 can be so slow.

iainmerrick 8y ago

I did say “one of the goals”. I don’t see how those examples are relevant. Why would that last one be faster? I agree that the OpenBSD code here is good, no more and no less than needed. I assumed the grandparent was referring to cases where an O(n) algorithm is used where it might be O(log n) or O(1) with just a little more effort. It’s a tradeoff, sure, and in some cases linear searches can work surprisingly well, but in general I think this kind of thing should always be considered in good code. Micro-optimizations like inline assembly for inner loops may or may not be a good idea, depending on the application. All else being equal, I’d certainly agree that good clean code would not use assembly.

josefx 8y ago

How is the coreutils true faster? I would expect the openbsd true to be the fastest, it doesn't need to spawn a subshell and it doesn't do more than the posix specification requires (afaik --help/--version should be ignored).

moviuro 8y ago
Experience shows it's faster. It's just weird, but it's like that. time { for i in $(seq 1 10000); do /path/to/true; done; }
- iainmerrick 8y ago
  What are you comparing against what there? Two C executables with the same compiler flags on the same OS?

hultner 8y ago

Is the gnu-coreutils true much faster? I have a hard time seeing how return 0 can be so slow.