Before we tell you which one is a few nano-seconds faster, you have to tell us what you're going to do with the time you save.

There's also initializing them with a list ... generally better with constants.

my ( $var1, $var2 ) = ( $FIRST_INDEX, $SECONDS_IN_A_YEAR );
[download]

You left out the following option:

my( $var1, $var2 ) = (
    subroutine0_with_return_value(),
    subroutine1_with_return_value()
);
[download]

None of them is appreciably better than the other from a CPU or memory perspective. When optimizing code for speed, you should first determine where the bottlenecks are (profile), and then look at ways of reducing that portion of the code's Big-O footprint. Optimizing something from O(1) to O(1) is Big-O-Meaningless. But taking a O(n^2) algorithm and replacing it with something O(n) is meaningful. Besides, if you're relying on nuances between my( $var1, $var2 ); and my $var1; my $var2, you're betting on undocumented performance nuances remaining equal from one version of Perl to the next, when in reality there are no guarantees that such undocumented nuances won't change in the future.

I think this one looks the cleanest:

my( $var1, $var2 ) = (
    subroutine0_with_return_value(),
    subroutine1_with_return_value()
);
[download]

but I'm lazy and I find that:

my $var1 = sub_w_ret_val1();
my $var2 = sub_w_ret_val2();
[download]

is the easiest to think through, especially when assigning several return values.

but I was taught that:

public static void main(){
    int var1, var2;
    //declare more variables here
    var1 = sub_w_ret_val();
    var2 = sub_w_ret_val();
}
[download]

(note the language change)

was the correct method for declaring variables.

while I'm not saying I find the third is the best method for declaring and using variables, I sometimes find myself doing the Perl (is it Perl or perl?) equivalent.

my $file1, $file2
my $var1, $var2

$var1 = &sub_w_ret_val();
$var2 = &sub_w_ret_val();
[download]

any way, that's my two cents on code writing optimization.

That third example is the vestigial remnant of ancient compilers and language versions which care more about what the computers of the day used to do than usability.

(Your final example has prototype behavior you likely did not intend.)

The cost of lexical variable declaration occurs solely during compilation time, and there are better ways to improve compilation time (trimming @INC, for example) if that's a problem (and it's rarely a problem).

> The cost of lexical variable declaration occurs solely during compilation time

IMHO "solely" is wrong, for instance lexicals are initialized to undef and if you check the reference of a variable declared in the head of a loop you can observe that they can change, i.e. there is no singular allocation overhead at compile time.

Furthermore there is an opcode executed at runtime for this (see line3)

perl -MO=Concise -e 'my $a;$a=1'
8  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v:{ ->3
3     <0> padsv[$a:1,2] vM/LVINTRO ->4
4     <;> nextstate(main 2 -e:1) v:{ ->5
7     <2> sassign vKS/2 ->8
5        <$> const[IV 1] s ->6
6        <0> padsv[$a:1,2] sRM* ->7
[download]

Anyway this is one of the last places I would consider for optimizations.

Cheers Rolf

I had meant parsing time, but you're right; I hadn't realized there exists an optimization for declare-and-assign.

“At so-many billion operations per second, these days, no one can hear you scream.”

Just focus your attention on designing and writing your code so that it is both robust and clear.   Rely upon the things that the Perl Implementors do for you (which is, after all, constantly improving), and don’t try to “second guess” what they are up to.   Just write code that is robust and clear.