my @PRC_PRIV = <FILE>;
my @PRC_PRIV_ONLY = grep /Run as/ .. /^ /, @PRC_PRIV;
with this:
my @PRC_PRIV_ONLY = grep /Run as/ .. /^ /, <FILE>;
And measure if you get any performance improvement.
Another point is that you may want to include use strict; and use warnings; near the top of your program and declare your variables with the my operator. This is a recommended good practice which will save you a lot of debugging time.
| [reply]
[d/l]
[select] |
Thanks! I get about a 1ms improvement doing it that way, using "time" and after serveral iterations testing both ways. Small, but measurable.
I left off the "use warnings" and "use strict" as well as the variable declarations for this post in interest of brevity. But I always do both.
| [reply] |
Just 1 ms? I thought it would be more. Against a total running time of how long?
I left off the "use warnings" and "use strict" as well as the variable declarations for this post in interest of brevity. But I always do both.
Fine, but then, you should rather declare your variables where you use them (in the smallest possible lexical scope), not at the top of your program. For example, you may have something like this:
foreach my $PRIV(@PRC_PRIV_ONLY) {
chomp($PRIV);
next if ($PRIV =~ m/Run|^ /);
my ($USER, $HOSTN, $CMDN) = split(" ", $PRIV, 3);
if (defined($USER)) {
print "$PRC_GRP,$USER,$HOSTN,$CMDN \n";
}
}
This way, you are defining truly local variables, and that's a good protection against silly but sometimes nasty bugs. Here above, $PRIV is scoped to the foreach loop, if you use it accidentally somewhere else in the program (which would have no sense), you'll get a compile error telling you that you are doing something wrong with it, and this is much better than having to chase the obscure reason why you don't get the output you expect. Similarly, the $USER, $HOST and $CMDN variables are scoped from the place they are declared to the end of the foreach loop. You'll be told by the compiler if you inadvertently use them where they should not be used. | [reply]
[d/l] |