Re: I think I just found a good reason to use backticks in a void context.

[merlyn]

The reduction in time is not because of backticks, but because you're avoiding the shell metachars, meaning that Perl can go directly to the command, rather than forking the shell first.

If you made the test fair, by perhaps adding a semicolon to the end of your backtick command, you'd see that you're saving nothing, and perhaps even spending more time capturing things that you're just going to ignore.

[OfficeLinebacker]

OK, I don't understand what you mean by "fair." I found a way to do something that's faster than another way of doing it. I don't get how making something faster that works is somehow perceived as a bad thing. You say

The reduction in time is not because of backticks, but because you're avoiding the shell metachars, meaning that Perl can go directly to the command, rather than forking the shell first.

As far as I can tell, using backticks is precisely what allows me to avoid using shell metacharacters (I am assuming you mean > and &). I guess I am having trouble understanding your position.
Do you have a better alternative?

[Errto]

I think merlyn's point is that in the OP, you seem to be claiming that it is using backticks itself which makes the progam faster, whereas he is pointing out that the actual cause is the lack of metacharacters. So if you were to use system instead of backticks, but still without redirection or other metacharacters, you would get the same benefit. Therefore it's not really fair to claim that the backticks made the difference.

[OfficeLinebacker]

I agree that if I had used system(), only with no redirection, the performance would probably be the same. I didn't try that, but I did try backticks WITH redirection and got a similar penalty (or loss of efficiency?) to using system() with redirection. I noted that in an update to the OP. I am sorry if I was unfair.

Tell me, is the following an accurate characterization:


By using backticks, I am effectively making the inside of my program the system call's STDOUT. Using backticks in a void context is the functional equivalent of redirecting output of the system call to /dev/null. With backticks, the computer has to do less work (and the programmer has to do less typing).

I don't mean to endorse of the practice by the above statements.

[Aristotle]

Using backticks is not the only way of avoiding the shell. Pass a list to system (or to a three-arg pipe-open for convenient output suppression) and you get the same effect.

So no, this isn’t a reason to use backticks in void context; it is merely a reason to avoid invoking the shell when you don’t need it. Even if backticks were required for that, saving a couple of microseconds here and there wouldn’t constitute a good reason to do it, as per the topic.

[merlyn]

Right... one that's more fair would be to fork yourself and close STDOUT and STDERR, which would probably be even faster. Something like:

defined(my $kidpid = fork) or die "cannot fork: $!";
unless ($kidpid) {
  close STDOUT;
  close STDERR;
  exec "your", "multiarg", "command", "here";
  die "$!";
}
waitpid($kidpid, 0);

That'd be the equivalent to your backtick-that-just-happens-to-not-invoke-the-shell, but probably even more efficient.