uninitialized value warnings and run time

[julia]

I'm reviewing a script to try to identify why it takes so ong to
execute.

It generates a lot (thousands) of uninitialized value warnings.

Does not properly initializing variables increase the run-time?

 

[julia]

Thanks.

This confirmed my suspicions about where the majority of the time was
being spent.

It also provides some encouragement for moving blocks of code into
subroutines instead of keeping them inline (although I do sometimes
wonder if the overhead associated with a subroutine outweighs the
benefit compared with a block of inline code that is only ever called
from one location).

Julia

 

[J. Gleixner]

Thanks.

This confirmed my suspicions about where the majority of the time was
being spent.

It also provides some encouragement for moving blocks of code into
subroutines instead of keeping them inline (although I do sometimes
wonder if the overhead associated with a subroutine outweighs the
benefit compared with a block of inline code that is only ever called
from one location.

While subroutines are a good coding practice, moving code that's only
called once into a subroutine won't improve the run-time. Figure
out why it's slower than expected and code/optimize as needed.

 

[Uri Guttman]

j> It also provides some encouragement for moving blocks of code into
j> subroutines instead of keeping them inline (although I do sometimes
j> wonder if the overhead associated with a subroutine outweighs the
j> benefit compared with a block of inline code that is only ever called
j> from one location).

my rule is to minimize inline code (except for very short scripts). subs
are a major way to ORGANIZE your code and logic flow. when i see long
linear scripts i want to pull out my hair (what little of it seems
left). i have a perloncall.com client (a regular here who recently
gave me such a script to for code review. we are slowly refactoring it
into almost all subs so you can hide less important code (stuff like get
a dbi connection, get cgi params, etc.) and see the real flow. subs have
two major purposes but usually only one, code reuse, is taught. code
organization is just as important and if you are concerned about the sub
call overhead you are prematurely microoptimizing.

uri

 

[Uri Guttman]

JG> While subroutines are a good coding practice, moving code that's only
JG> called once into a subroutine won't improve the run-time. Figure
JG> out why it's slower than expected and code/optimize as needed.

but it can help you isolate the slower code. it is easier to do a
profile on subs than with a long linear script. rarely would just a line
or two of code be the bottleneck. it is usually a poor data structure or
poor coding, both of which are easier to analyze if the code is broken
up into logical and reasonably sized subs. see my other post for why i
say you should have minimal main line code.

uri

 

[Thrill5]

I'm reviewing a script to try to identify why it takes so ong to
execute.

It generates a lot (thousands) of uninitialized value warnings.

Does not properly initializing variables increase the run-time?

After you have checked every instance of the warning and you know that the
"unitialized" value is not a problem, you can turn this particular warning
off in your script. You really do need to check each instance of the
warning because you will find instances where this warning is indeed a
potential problem.

use warnings;
no warnings 'uninitialized';

Scott

 

[Uri Guttman]

T> After you have checked every instance of the warning and you know that the
T> "unitialized" value is not a problem, you can turn this particular warning
T> off in your script. You really do need to check each instance of the
T> warning because you will find instances where this warning is indeed a
T> potential problem.

T> use warnings;
T> no warnings 'uninitialized';

that is a very bad thing to do. i won't get into it as many past threads
have covered it. worrying about initialization time when you can't even
figure out how to stop uninitialized warnings is such a premature
optimization symptom.

uri