Efficiency and scoping 'my' variables

[david scholefield]

Not easily being able to look into the perl interpreter code, does anyone
have any idea on whether or not declaring a new _my_ variable is more
efficient when declared inside a loop (creating a new instance every
time), or declared outside the loop, or whether there is no great
difference.

By efficiency I mean both
space, and speed (though as the loop body completes each iteration I assume
the variable reference count reduces to zero and it is destroyed anyway, so
I guess space isn't a issue?)

e.g.
{
my $someVal;
while ($loopcontrol)
{
... use $someval in some way
}
}

is more efficient than (?)

while ($loopcontrol)
{
my $someVal;
... use $someval as before
}

I realise that there is a functional difference in that by declaring inside
the loop, any old value is over-written, but assuming that isn't an issue...

david
emology.com

 

[Anno Siegel]

Not easily being able to look into the perl interpreter code, does anyone
have any idea on whether or not declaring a new _my_ variable is more
efficient when declared inside a loop (creating a new instance every
time), or declared outside the loop, or whether there is no great
difference.

In deciding the scope of a variable, efficiency stays out of the
consideration. The rule is to put the variable in the smallest
possible scope.

By efficiency I mean both
space, and speed (though as the loop body completes each iteration I assume
the variable reference count reduces to zero and it is destroyed anyway, so
I guess space isn't a issue?)

Both space and time aren't issues here. You start thinking about
efficiency when your program is too slow. In that case, shuffling
loop variables around won't bring the breakthrough you need.

[code with variable declared inside/outside while-loop]

I realise that there is a functional difference in that by declaring inside
the loop, any old value is over-written, but assuming that isn't an issue...

It's always an issue. If functionality doesn't demand the variable outside
the loop, put it inside.

Theoretically, the point is clear. The space requirement is the same,
as you observed. Obviously, the run-time effect of "my" happens more
often when the variable is declared inside the loop. The difference
is small (use Benchmark to measure it on your machine, if you can).

Consider it the cost of correct scoping. It's one of the last things you
want to trade for efficiency.

Anno

 

[david scholefield]

In deciding the scope of a variable, efficiency stays out of the
consideration. The rule is to put the variable in the smallest
possible scope.

Good advice, generally...

Both space and time aren't issues here. You start thinking about
efficiency when your program is too slow. In that case, shuffling
loop variables around won't bring the breakthrough you need.

that's what I was asking... thanks for the answer... I guess that
variable declaration isn't a time-intensive activity at run-time

thanks
david

 

[Martien Verbruggen]

Good advice, generally...
Indeed.


that's what I was asking... thanks for the answer... I guess that
variable declaration isn't a time-intensive activity at run-time

There's a slight overhead, but it's something in the order of 10%.
Something like that, as Anno already said, won't generally give you
the savings you need when you think your program is too slow.

90% of slowness problems in code, irrespective of the language, can
really only be solved by changing the algorithm. The other 10% can
most often be fixed most easily by throwing more hardware at it. There
is a fraction that can be made to go faster by fiddling with the scope
of variables [1].

Martien

[1] some fiddles with the scope of variables should properly be seen
as algorithmic changes. For example, changing an OO program to not
instantiate an object in a tight loop, but instead to re-use an object
created outside of the loop, or to use a singleton, is not just a
scope change, even though it can often result in dramatic speed
differences.

 

[fifo]

Good advice, generally...


that's what I was asking... thanks for the answer... I guess that
variable declaration isn't a time-intensive activity at run-time

Ignoring for a moment that "premature optimisation is the root of all
evil", you can always find out for yourself how fast different
constructs are by using the Benchmark module:

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

sub doSomething { }

timethese(10000, {
outside => q{
my $someVal;
for (0..100)
{
doSomething($someVal);
}
},
inside => q{
for (0..100)
{
my $someVal;
doSomething($someVal);
}
}});
__END__
Benchmark: timing 10000 iterations of inside, outside...
inside: 2 wallclock secs ( 2.29 usr + 0.00 sys = 2.29 CPU) @ 4366.81/s (n=10000)
outside: 2 wallclock secs ( 1.89 usr + 0.00 sys = 1.89 CPU) @ 5291.01/s (n=10000)