Is there any (performance) benefit to importing functions?

I've noticed that there are some functions that don't require use-ing or require-ing to use: for instance, the Time::HiRes:: functions, the utf8:: utility functions, Cwd::getcwd(), etc.

This isn't quite correct - the only one of those that is loaded automatically by Perl is utf8:

$ perl -wMstrict -le 'print Time::HiRes::gettimeofday()'
Undefined subroutine &Time::HiRes::gettimeofday called at -e line 1.
$ perl -wMstrict -le 'print Cwd::getcwd()'
Undefined subroutine &Cwd::getcwd called at -e line 1.
$ perl -wMstrict -le 'print utf8::valid("foo")'
1
[download]

However, if you have noticed this behavior in a longer script, then note that if any other piece of code you've loaded does e.g. use Cwd; or require Cwd;, then you will be able to do Cwd::getcwd() in your code regardless of whether or not you have loaded Cwd yourself. This is because of the way Perl's Symbol Tables work: once Perl sees package Cwd; sub getcwd { ... } or equivalent, then the symbol table entry &Cwd::getcwd will exist.

where do I find a reference/list of these functions which require no require or use to use?

It's pretty rare that Perl loads modules automatically, and I don't think there is a reference other than a few mentions sprinkled throughout the docs. Really the only one I can think of off the top of my head at the moment is utf8, as I showed above. Then there are those that are loaded on demand only, such as File::Glob - note how I have to use the glob operator <*> before I can access File::Glob::*:

$ perl -wMstrict -le '     print join ",", File::Glob::bsd_glob("{x,y}
+={a,b}")'
Undefined subroutine &File::Glob::bsd_glob called at -e line 1.
$ perl -wMstrict -le '<*>; print join ",", File::Glob::bsd_glob("{x,y}
+={a,b}")'
x=a,x=b,y=a,y=b
[download]

Then there are those that are documented to be loaded automatically, such as IO::Handle and charnames (at least in recent versions of Perl), but some quick testing seems to show that these don't behave like File::Glob in that I still have to use them explicitly if I want to access the functions in the modules.

Also, note there isn't really a standard behavior for modules in Perl. In this node I wrote at length about how importing from modules works, and note some of the general statements such as "Because Perl is very flexible in what it allows module authors to do, it isn't easy to give some general rules as to how modules act, beyond some guidelines and best practices about how modules should be written, and based on that some rules of thumb of what to expect. So you'll have to look at the documentation of each of the modules to see what effects useing them will have." I also recommend a thorough read of perlmod.

What does this mean? I would recommend that you always explicitly use modules whose functions you want to use in your code. That way, a reader of the code won't be confused where those functions are coming from, and you wouldn't be relying on any action-at-a-distance behavior, as I think you are when you talk about e.g. Cwd::getcwd() being loaded automatically. The only exception to this rule might be utf8, because use utf8; has the special effect of declaring the source code to be encoded in UTF-8. (If I think of or am reminded of any other such exceptions I can update this node.)

But that got me thinking also about (2nd question) whether or not it makes a performance difference when using "long" package names

A Benchmark with the following constructed single test case on my machine seems to show that there is no significant difference between the two across various versions of Perl.

Read more... code (522 Bytes)

I mean does perl have to convert long names into paths or something to locate the function everytime

No, although I'm not an expert on the internals, I'm pretty sure Perl does not have to do that. In my example code above, note that the function call bar() is basically just short for main::bar() (since the default package is main), and both main::bar() and Foo::bar() refer to the same piece of code.

What does this mean? In my opinion the performance difference is small enough that it should be ignored. What shouldn't be ignored is that imported functions save typing. (Another smaller factor to consider might be testing: If you use the full package name, mocking those functions is a little more annoying because you have to override them in the originating package instead of just the package under test.)

Update: Typo fix and minor re-wording for clarity.

[reply]
[d/l]
[select]

...This isn't quite correct - the only one of those that is loaded automatically by Perl is utf8

Dang yeah you're right about that. I should have tested in a bare script beforehand. XSLoader however appears to still be callable using the long name without require, though.

EDIT: Never mind, XSLoader does require require, my bad again.

[reply]
[d/l]
[select]

The documentation will (well, should) explain which functions are "exported" by default, and which ones you have to ask for. If not, look in the module's code, and in the @EXPORT array, these are the ones exported by default. The @EXPORT_OK are ones you need to specifically request when loading the module. One can also use %EXPORT_TAGS hash to create tags that can bundle certain groups of functions.

For example, my Bit::Manip distribution exports none of its functions by default, you have to ask for them individually, or you can use the :all tag to load them all in bulk:

use Exporter;
our @ISA = qw(Exporter);
 
our @EXPORT_OK = qw(
    bit_get
    bit_set
    bit_clr
    bit_bin
    bit_count
    bit_mask
    bit_tog
    bit_toggle
    bit_on
    bit_off
);
 
our %EXPORT_TAGS;
$EXPORT_TAGS{all} = [@EXPORT_OK];
[download]

My WiringPi::API goes one step further, and does use tags to bundle. The distribution is a wrapper of a C library. You can read the export implementation on lines 11-61, but the gist of it is that I provide three tags:

our @EXPORT_OK = (@wpi_c_functions, @wpi_perl_functions);
our %EXPORT_TAGS;
 
$EXPORT_TAGS{wiringPi} = [@wpi_c_functions];
$EXPORT_TAGS{perl} = [@wpi_perl_functions];
$EXPORT_TAGS{all} = [@wpi_c_functions, @wpi_perl_functions];
[download]

The first tag exports the functions with their original C names (camelCase). The second exports the Perl wrapped names (snake_case). The third, is pretty clear, exports the lot of them. Looking at it now, I don't know why I didn't just set all to @EXPORT_OK, but I digress...). To use them in a use statement, you'd specify them as :wiringPi, :perl or :all.

It's considered bad practice to blindly export all subs by default, as there is high risk that you'll clobber an existing symbol table name. In my App::CopyrightImage module, I have a single public function, which I do export by default:

our @EXPORT = qw(imgcopyright);
[download]

The documentation explicitly states we export the one function automatically.

To further, I've even gone beyond using Exporter, and just pee'd all over the user's symbol table to stuff in a function:

sub import {
    my ($class, %opts) = @_;
 
    $self = __PACKAGE__->_new(%opts);
 
    my $sub_name = $opts{sub_name} ? $opts{sub_name} : 'plugins';
 
    {
        no warnings 'redefine';
        no strict 'refs';
 
        my $pkg = (caller)[0];
        *{"$pkg\::$sub_name"} = \&_plugins;
    }
}
[download]

...but that is something rarely done (and shouldn't be done unless there's a very good reason). Of course, that documentation also explicitly and clearly states we do this.

As far as benchmarking, I don't really care. It's startup cost, a one-time thing. To me, benching that would pretty much be far too much optimization without enough benefit. However, if you do bench it, please do post results.

[reply]
[d/l]
[select]

However, if you do bench it, please do post results.

#!/usr/bin/perl
use warnings;
use strict;

{   package Exported;
    use Time::HiRes qw{ gettimeofday };
    sub foo { gettimeofday }
}

{   package FullName;
    use Time::HiRes;
    sub foo { Time::HiRes::gettimeofday }
}

{   package CodeRef;
    use Time::HiRes;
    *foo = *Time::HiRes::gettimeofday{CODE};
}

use Test::More tests => 2;
cmp_ok abs(Exported::foo() - FullName::foo()), '<', 1e-4, 'almost same
+';
cmp_ok abs(Exported::foo() - CodeRef::foo()),  '<', 1e-4, 'almost same
+';

use Benchmark qw{ cmpthese };
cmpthese(-3, {
    exported => \&Exported::foo,
    fullname => \&FullName::foo,
    coderef  => \&CodeRef::foo,
});
[download]

On my i3 notebook:

Rate exported fullname coderef
exported 3537621/s -- -6% -72%
fullname 3753422/s 6% -- -70%
coderef 12498685/s 253% 233% --

Update

haukex

sub

    coderef => sub { CodeRef::foo() },
[download]

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

[reply]
[d/l]
[select]

Thanks choroba!

So export and fullname are negligibly different, but holy crap coderef! :)

[reply]

I've noticed that there are some functions that don't require use-ing or require-ing to use: for instance, the Time::HiRes:: functions, the utf8:: utility functions, Cwd::getcwd(), etc.

This isn't quite correct - the only one of those that is loaded automatically by Perl is utf8:

$ perl -wMstrict -le 'print Time::HiRes::gettimeofday()'
Undefined subroutine &Time::HiRes::gettimeofday called at -e line 1.
$ perl -wMstrict -le 'print Cwd::getcwd()'
Undefined subroutine &Cwd::getcwd called at -e line 1.
$ perl -wMstrict -le 'print utf8::valid("foo")'
1
[download]

However, if you have noticed this behavior in a longer script, then note that if any other piece of code you've loaded does e.g. use Cwd; or require Cwd;, then you will be able to do Cwd::getcwd() in your code regardless of whether or not you have loaded Cwd yourself. This is because of the way Perl's Symbol Tables work: once Perl sees package Cwd; sub getcwd { ... } or equivalent, then the symbol table entry &Cwd::getcwd will exist.

where do I find a reference/list of these functions which require no require or use to use?

It's pretty rare that Perl loads modules automatically, and I don't think there is a reference other than what is mentioned spread out in the docs in a few places. Really the only one I can think of off top of my head at the moment is utf8, as I showed above. Then there are those that are loaded on demand only, such as File::Glob - note how I have to use the glob operator <*> before I can access File::Glob::*:

$ perl -wMstrict -le '     print join ",", File::Glob::bsd_glob("{x,y}
+={a,b}")'
Undefined subroutine &File::Glob::bsd_glob called at -e line 1.
$ perl -wMstrict -le '<*>; print join ",", File::Glob::bsd_glob("{x,y}
+={a,b}")'
x=a,x=b,y=a,y=b
[download]

Then there are those that are documented to be loaded automatically, such as IO::Handle and charnames (at least in recent versions of Perl), but some quick testing seems to show that these don't behave like File::Glob in that I still have to use them explicitly if I want to access the functions in the modules.

Also, note there isn't really a standard behavior for modules in Perl. In this node I wrote at length about how importing from modules works, and note some of the general statements such as "Because Perl is very flexible in what it allows module authors to do, it isn't easy to give some general rules as to how modules act, beyond some guidelines and best practices about how modules should be written, and based on that some rules of thumb of what to expect. So you'll have to look at the documentation of each of the modules to see what effects useing them will have." I also recommend a thorough read of perlmod.

What does this mean? I would recommend that you always explicitly use modules whose functions you want to use in your code. That way, a reader of the code won't be confused where those functions are coming from, and you wouldn't be relying on any action-at-a-distance behavior, as I think you are when you talk about e.g. Cwd::getcwd() being loaded automatically. The only exception to this rule might be utf8, because use utf8; has the special effect of declaring the source code to be encoded in UTF-8. (If I think of or am reminded of any other such exceptions I can update this node.)

But that got me thinking also about (2nd question) whether or not it makes a performance difference when using "long" package names

A Benchmark with the following constructed single test case on my machine seems to show that there is no significant difference between the two across various versions of Perl.