Reults of my fairest approximation:

                  Rate          copy        nocopy   inline_copy inlin
+e_nocopy
copy          534208/s            --           -9%          -13%      
+    -23%
nocopy        587704/s           10%            --           -4%      
+    -16%
inline_copy   610942/s           14%            4%            --      
+    -12%
inline_nocopy 697762/s           31%           19%           14%      
+      --
[download]

use strict;
use warnings;

use Benchmark qw( cmpthese );

sub attrib_copy   { my ($self) = @_; $self->{attrib} }
sub attrib_nocopy {                  $_[0]->{attrib} }

our $self = bless({ attrib => 'some_value' });

my %tests = (
    copy          => 'my $x = do { local @_ = $self; &main::attrib_cop
+y };',
    nocopy        => 'my $x = do { local @_ = $self; &main::attrib_noc
+opy };',
    inline_copy   => 'my $x = do { local @_ = $self; my ($self) = @_; 
+$self->{attrib} };',
    inline_nocopy => 'my $x = do { local @_ = $self;                  
+$_[0]->{attrib} };',
);

$_ = 'use strict; use warnings; our $self; ' . $_
    for values %tests;

cmpthese(-3, \%tests);
[download]

See how you can almost get the same benefit from not copying the @_ into local vars?

If you are worried about optimization on that level then Perl may not be the best choice for whatever you are trying to do. Perl is fast when most of the work is being done in standard functions which are part of the interpreter.

Maybe refactoring the code will help? If you have specific examples that demonstrate the problem, post em here and we'll see what may be done to improve performance.

I am not currently experiencing slow performance but the functions are only being called about 120,000 times when the script is being run.

This is more about curiosity to learn about what optimization options are before me, and if indeed inlining exists in perl and is useful in perl.

Currently I don't have any examples to post, but I will try to post some soon.

Maybe codefilters (see Filter::Simple) were meant to replace them, but I don't recommend their use.

Anyway perl knows the term "inlining" for subs but they are restricted to constant return values only (see Constant Functions)

An other approach would be dynamic code generation with a template-system and eval.

One more could be to use labels and gotos to avoid the function overhead. (you can also goto directly into a functionbody, but you have to take care by your self how to get back to the caller ...)

Anyway perl is not meant for these kinds of optimizations, the original concept was to delegate time critical tasks to embedded c code (see perlxs)

UPDATE:added some links

Thanks for the thoughts and suggestions. I will read up on those. I think I can already tell more than a few will at least be useful for investigating.

About whether or not these would be appropriate, I'm not even sure if I would these optimizations after I successfully created them. I will do some profiling to see how things perform with and without.

Mostly I am just morbidly curious to know about the inlining process and similar optimization processes.

The Agile Process folks have a saying -- YAGNI. Don't spend time in the design phase on anything except solving the current problem at hand. All too often any optimization during your design phase will turn into examples of the 'You Ain't Gonna Need It" principal in action....

Do you have something that's running too slowly? ... or are you thinking of doing a pre-emptive optimization?

If the former, you might present the code and someone here might have a way to improve it. If it's the latter, you're probably wasting your time. It's generally better to have something work and then improve it if it needs it. Otherwise, just move on to the next task in the queue!

Currently nothing is slow. The program is already written and I'm just going through improving the code style by separating repeated portions out into functions. This made me wonder about optimizations and this is just curiosity.

Even in *C* inline rarely gives a significant speedup these days. If your code is running too slowly, then the first two things to look at are, in my experience:

• run the problem function fewer times
• change the algorithm