zlacker

>>taubek+(OP)
I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.

>>EdScho+Oa
What ancient system makes a speed difference in command lookup in PATH?

>>mekste+fv
Calls like execvp() do little more than splitting PATH on ':', followed by repeatedly invoking execve() on ${dir}/${filename}. The fewer elements you have in PATH, the fewer execve() calls need to be performed in the worst case.

>>EdScho+tz
Sounds like they need fixed for inefficient handling of simple operation.

>>mekste+nA
I’m assuming you are proposing to stat each candidate before trying to execve it. I’m also assuming that a stat system call is roughly as expensive as an execve of a nonexistent or non-executable path.

For every failed candidate, you are doing one system call, so roughly the same cost each way.

Now if you just do an execve, you’re just paying that cost. If you stat first, you pay the cost of another system call that doesn’t change the flow of your program at all (a nice way of saying you’re wasting time).

Unless stat is dramatically faster than exec on a nonexistent or non-executable path, there’s never a case where this is better.