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

backticks may be easy and perform the same as 'open' on Windows, but backticks perform worse on *nix for some reason. The following code:

use strict;
use warnings;
use Time::HiRes qw(time);
use POSIX qw(strftime);

timestamp();
my $fred = `echo plenty of fish`;
timestamp();
warn $fred;
timestamp();
open my $fh, 'echo ' . $fred . ' |';
$fred = <$fh>;
close $fh;
timestamp();
warn $fred;
timestamp();

sub timestamp {
    my $t = time;
    my $date = strftime "%Y%m%d %H:%M:%S", localtime $t;
    $date .= sprintf ".%03d", ($t-int($t))*1000; 
    print $date, "\n";
}
[download]

produced the following results on three platforms:

Windows: backtick: 12ms open: 11ms

SunOS: backtick: 17ms open: 8ms

Debian: backtick: 1ms open: 0ms

It doesn't look too significant with the trivial subprocess above, but if the subprocess is heavier the difference increases disproportionately on Debian - enough to change site standards.

One world, one people

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

Replies are listed 'Best First'.
Re^3: How to capture compile errors from child program? by kennethk (Abbot) on Aug 03, 2015 at 18:45 UTC
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.	[reply] [d/l] [select]
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]
Re^3: How to capture compile errors from child program? by Anonymous Monk on Aug 03, 2015 at 15:25 UTC
One sample doth not a Benchmark make.	[reply]