Re: Re: is 'my' that much faster than 'local'?

[gregw]

Great, thanks! ~10%, more if calling local repeatedly in loops is what I was looking for. We don't call local within any loops; all the locals are at the top, just inside the sub wrapper { } block which surrounds all the other code in the script (except for the call to &wrapper).

I think I'm avoiding the problem you raise in the second paragraph by making *all* variables local, with a long set of "local $wrapper::varname;"s at the top of the wrapper subroutine. Thus subroutines pass variables by using local variables all defined in their parent (or grandparent) subroutine, &wrapper. So I don't think I have any globals that local would mess with. And the few modules we're using are pretty common so I presume they're well-behaved in regards to using globals.

[kal]

Some of the answers here seem to be missing the point - or maybe it is me missing the point? The transformation you describe on your code is, as I understand it,

sub Main {
    local ($list_of_vars);
    
    [old code, which thinks the above locals are globals]
}

Yes? In which case, the 'global' variables (global to the old code, but not _global_ :) are only instantiated _once_, throughout the lifetime of the program. So, unless the main amount of work you do is defining a load of variables (highly unlikely), you won't gain anything switching local to my.

To be honest, if you want faster scripts with minimal optimization (i.e., no algorithm analysis, etc.) just run it on a faster machine. A lot of people will baulk at that, but look at the costs involved and make the decision.




Cheers.

[tilly]

You typically do a lot of work in accessing variables. Lexical variables bind at compile-time, global variables involve a run-time lookup. Hence the performance difference.

Personally I suspect that with that much code, all global, there are serious algorithm mistakes scattered around that cannot be seen let alone fixed because of the hole that they dug for themselves...

[gregw]

Exactly. :)