I tested this idea out with this code.
#!/usr/bin/perl -w
use strict;
use Benchmark;
{
# Start the benchmark
my $start = new Benchmark;
for(1..1000) {
print qq($ENV{PATH}\n);
}
# End the program and return the Benchmark time
my $end = new Benchmark;
print "Processing time was...\n";
print timestr(timediff($end, $start)) . "\n";
}
sleep 10;
{
my $foo = $ENV{PATH};
# Start the benchmark
my $start = new Benchmark;
for(1..1000) {
print qq($foo\n);
}
# End the program and return the Benchmark time
my $end = new Benchmark;
print "Processing time was...\n";
print timestr(timediff($end, $start)) . "\n";
}
Using 1000 iterations in the loop, the results I got were...
Loop using $ENV{PATH}: 12 wallclock secs ( 0.13 usr + 0.15 sys = 0.2
+8 CPU)
Loop using $foo: 11 wallclock secs ( 0.07 usr + 0.05 sys = 0.12 CPU)
So it looks like there was some performance gain in that example using the stored var instead of directly accessing the hash value. I would guess that the second loop was faster because the application didn't have to search through a hash for the value, but someone else who has a better idea of the internal workings of Perl might be able to tell you more.
Personally, if I'm using a lot of environment variables, I like to assign them to variable names so I can assign them a name I want and not have to worry about typing $ENV{FOO} again and again.
Rich36
There's more than one way to screw it up...
|