Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Fastest way of calling a subroutine

As far as I know, in Perl, we can call a subroutine from a Module by using these techniques:

  • Export subroutine foo, import the module which has this subroutine. Finally call it in your perl script.
  • Create an Object of that Module in your perl script finally call foo using that Object.
  • Directly call foo using its path, like this myDir::Module::foo();.

If I am always confused which is better way of calling a subroutine foo. If I have a dynamic script, which I run from the browser and not command line, which approach one should go for so that the script takes less time.

Thanks.

like image 855
Krishnachandra Sharma Avatar asked Dec 13 '25 13:12

Krishnachandra Sharma


1 Answers

There is a difference between the fastest, and the best way to call code in Perl.


Edit: please see simbabques answer as well. He especially covers the differences between #1 and #3, and why you would use either.


#1, #3: Function calls

Your #1 and #3 are identical: The subroutine has an unique name in the globally visible namespace. Many names may map to one subroutine via aliases, or importing a module.

If the name of the function you are calling is known at compile time, the sub will be resolved at compile time. This assumes that you don't spontaneously redefine your functions. If the exact function is only known at runtime, this is only a hash lookup away.

There are three ways how functions can be called:

foo(@args);
&foo(@args);
@_ = @args; goto &foo;

Number one (braces sometimes optional) is default, and validates your arguments against the sub prototype (don't use prototypes). Also, a whole call stack frame (with much useful debug information) is constructed. This takes time.

Number two skips the protoype verification, and assumes that you know what you are doing. This is slightly faster. I think this is sloppy style.

Number three is a tail call. This returns from the current sub with the return value of foo. This is fast, as prototypes are ignored, and the current call stack frame can be reused. This isn't useful very often, and has ugly syntax. Inlining the code is about an order of magnitude faster (i.e. in Perl, we prefer loops over recursion ☹).

#2: Method calls

The flexibility of OO comes at a hefty performance price: As the type of the object you call the message on is never known until runtime, the actual method can only be resolved at runtime.

This means that $foo->bar() looks up the function bar in the package that $foo was blessed into. If it can't be found there, it will be searched for in parent classes. This is slow. If you want to use OO, pay attention to shallow hierarchies (→ less lookups). Do also note that Perls default Method Resolution Order is unusual.

You cannot generally reduce a method call to a function call, even if you know the type.

If $foo if of class Foo, and Foo::bar is a sub, then Foo::bar($foo) will skip the method resultution, and might even work. However, this breaks encapsulation, and will break once Foo is subclassed. Also, this doesn't work if Foo doesn't define bar, but the method was defined in a parent class.

I am generally in favour of object orientation, until it is clear from benchmarks that this will not provide the performance you require.

like image 166
amon Avatar answered Dec 15 '25 06:12

amon



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!