Re^3: How to capture compile errors from child program?

First, it's not the weight of the subprocess, it's the number of invocations that would be problematic. Second, since you are only running your code once, there are all sorts of problems with your benchmark. Use Benchmark to actually test performance.

#!/usr/bin/perl
use strict;
use warnings;

use Benchmark qw(:all :hireswallclock) ;

cmpthese(20, {
    'Backtick' => sub{`echo plenty of fish` for 1 .. 10},
    'Open' => sub{for (1 .. 10){open my $fh, "echo plenty of fish |"; 
+<$fh>}},
});
[download]

outputs

           Rate     Open Backtick
Open     9.29/s       --      -1%
Backtick 9.35/s       1%       --
[download]

on my Windows box and

           Rate     Open Backtick
Open     85.8/s       --     -10%
Backtick 95.7/s      11%       --
[download]

on a Linux server (with iteration count upped to be meaningful).

As an aside, if you are optimizing away milliseconds of overall run time, you probably shouldn't be using Perl.

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Comment on Re^3: How to capture compile errors from child program? Select or Download Code

Replies are listed 'Best First'.
Re^4: How to capture compile errors from child program? by anonymized user 468275 (Curate) on Aug 04, 2015 at 09:01 UTC
Thanks for the tip about benchmark. But I don't agree one should abandon Perl just because one measures some snippet execution in milliseconds. What you are most missing here is that one of the main reasons to use Perl is to avoid shelling out (or in) at all, in the first place. So those milliseconds can and will be optimised away with Perl! Conversely it is much more of a challenge (if even remotely possible) to do so with scripting languages that are not based on C, especially re Perl access to C libraries. One world, one people	[reply]
Re^5: How to capture compile errors from child program? by kennethk (Abbot) on Aug 04, 2015 at 15:03 UTC
Optimization is highly use-case dependent. If a particular use case dictates that the difference between the invocation weight of backticks, open, IPC::Open3, pipe/fork/exec or any other flavor of external call will be problematic, then it's reasonably likely Perl is a bad choice of context. Perl is a great choice of language for optimizing programmer vs. computer times, and generally timing doesn't really matter as long as global execution time is less than a second. But even the most diehard adherent should be willing to question whether they've chosen the right tool for the job at hand. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply]