Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

package function calling

by BarMeister (Beadle)
on Jul 12, 2005 at 13:30 UTC ( #474272=perlquestion: print w/ replies, xml ) Need Help??
BarMeister has asked for the wisdom of the Perl Monks concerning the following question:

Are there any performance benefits/issues with doing the following?

use MyPackage::MySubPackage; MyPackage::MySubPackage::some_function(); opposed to...

use MyPackage::MySubPackage; some_function();

I am using mod_perl, use strict/warnings, etc...

Comment on package function calling
Select or Download Code
Re: package function calling
by halley (Prior) on Jul 12, 2005 at 13:44 UTC
    (1) Don't worry about performance unless there's an obvious performance problem. Especially don't worry about the performance of little features. This is called "premature optimization."

    (2) When you DO find a serious performance problem, attack the worst performance areas first. How do you know what's the worst? You Devel::Profile the code as a whole and Benchmark alternatives. Profiling and Benchmarking is the only sane way of discovering what portion of your program is taking the most time. Update: clarified myself reflecting L~R's corrections.

    (3) The specific feature you mention should have almost no effect on execution time, since the function name is entered into both symbol tables. The only difference I would guess would be how long it took the parser to parse the extra four tokens.

    [ e d @ h a l l e y . c c ]

      Ok maybe I should rephrase to ask which method is the "best practice" for doing that? I was asking just out of curiosity...since it is better to do something the right way the first time :-)
        If the symbol is imported, it's imported for a reason. This is typically for readability or convenience. Programs are usually more clear if they read smoothly without a lot of extra words and punctuation sprinkled in.

        However, if by being extra-verbose, your program gains clarity for those who are reading it, then go ahead. This can happen when more than one package might have a routine by similar names. If two packages have identical routine names, you might need to clarify the situation by specifying the package name.

        [ e d @ h a l l e y . c c ]

      I don't see how Benchmark is going to be a good solution in finding what the problem is. You need to profile to do that. Benchmark is designed to compare two or more functionally equivalent pieces of code not compare against itself.

      Cheers - L~R

Re: package function calling
by derby (Abbot) on Jul 12, 2005 at 13:47 UTC

    Not really. There's not enough info in your post but I assume the second version has some_func in the package's EXPORT array. The perfomance penalty is in the actual exporting not in the look-up.

    Unless your EXPORT array is insanely huge, the perfomance cost would be down in the noise - I would worry more about namespace pollution and collision before execution time.

    If you really care, just Benchmark the two approaches.

Re: package function calling
by polettix (Vicar) on Jul 12, 2005 at 13:51 UTC
    If module "MyPackage::MySubPackage" does not export functions by default, you're obliged to use the first version. Moreover, this version wipes away any ambiguity about where the function is coming from, so readability could improve. OTOH, if some_function is used frequently, the full specification could be more a noise than a readability improvement, so you'd probably find some way to import the function name and use the second approach. Just Huffman for programmers.

    I would be surprised if there were any performance issues related to the two approaches. But this is a place in which it is quite easy to be surprised.

    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.
      Ok thanks...I think that covers it...I think I will stick to fully qualified calls.

      Thanks for the advice.

        Before you go and do that, you should probably hear the reasons why it's sometimes (not always), appropriate to import functions into your namespace, or something similar.

        Consider the possibility that down the road, you have issues with MySubPackage in a script, but you still need it for other scripts on the system, so don't want to completely overwrite the module. You create MySubPackage2, which has the same interface as the original MySubPackage, and then you just need to change one line of code in this script:

        #use MyPackage::MySubPackage; use MyPackage::MySubPackage2; some_function();

        If you use fully qualified calls, then you have to go through the script, and find/replace everything, which might be more time consuming. You may also decide that you want to have some logic in your script that dynamically loads the proper 'some_function()' to be used throughout the script, based on other parameters -- in this situation, you want the lines of code that call the function to not worry about what they're actually calling.

        Sometimes, tradeoffs in execution time cuts down on the time and effort to change the code down the road, (is part of the issue with premature optimization, which halley mentioned)

Re: package function calling
by wfsp (Abbot) on Jul 13, 2005 at 11:33 UTC
    As an aside, for my own benifit I always use EXPORT_OK in the module.

    The script then needs to be:

    use MyPackage::MySubPackage qw(some_function);
    I find this helps show more clearly what has come from where.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://474272]
Approved by Tanalis
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (8)
As of 2014-11-28 12:45 GMT
Find Nodes?
    Voting Booth?

    My preferred Perl binaries come from:

    Results (196 votes), past polls