why are these so slow to import?

Well, if you think about it when you use Pod::Usage it has to parse the source of your code, extract the POD and process the POD to present usage info - that will all take time. You can save this by postponing the load until/unless it is actually needed (most runs will never need it, of course). The other option is to use pod2usage out-of-band in advance and just copy the output of that into your code instead statically.

I find that Getopt::Std is much faster than Getopt::Long. Its reduced functionality may well be worth the trade-off for you.

By "postponing until needed", do you mean something like eval q{use Pod::Usage}, whenever the help message is needed ?

Thanks for the pointer to Getopt::Std, I'll consider it the next time around. I've ended up coding a simple arg-parsing loop in the meanwhile (the repo is ssh_agent_share; quite trivial, but it seems I end up learning something new every time I reach back to perl).

use Pod::Usage;

# is the same as

BEGIN {
   require Pod::Usage;
   Pod::Usage->import();
}
[download]

BEGIN blocks execute at compile time, not run time.

Assuming that often you run without ever using the Pod functions, and you want to fire that module up only if you will be needing it, you could have a runtime flag like this:


if ($needPod)
{
    require Pod::Usage;
    Pod::Usage->import();
}
[download]

I leave it you to decide how this applies to your code. You have to do the require and import before using any functionality of Pod::Usage.

Usually GetOPt::Std is enough for me. I almost never use autodie and absolutely never use it in end user code.

I use this recipe in most scripts:

use Getopt::Long;
sub pod2usage { require Pod::Usage; goto \&Pod::Usage::pod2usage; }
GetOptions(
   ...
   ...
) or pod2usage(2);
[download]

I don't mind paying for Getopt::Long because I like its features, but there's no reason to load Pod::Usage unless the user screws up the commandline.

On that note, someone ought to contribute a patch to Pod::Usage that avoids loading anything until it gets called. Then I could skip that bit of ugly boilerplate in my code.

The eval q{use Pod::Usage}; will work, though those who are allergic to stringy evals will probably prefer something more like

require Pod::Usage;
Pod::Usage::pod2usage( ... );

It starts the engine, does a lot of initializing, has to load various modules from filesystem and if they are lots of pure Perl need to compile them, and probably need to repeat all this to import more dependencies.

So many things to consider, such that your benchmarks should be more detailed, probably using the NYT profiler.

I don't think anything below 0.3 secs is really worth worrying, but if you really need to run a program many times you should consider talking to a server with everything pre-initialized. That's the trick behind fast-cgi etc... You'll trade space for time like that.

But if that's not an option because you have too many different programs which need boosting, you could consider bundling all dependency into one big package with par-packer and precompiling them into a .plc with bytecode and store them in a ram-disk.

Disclaimer: Never tried that myself, cause as I said, Perl startup is usually fast enough for me. (perltidy probably being the only exception)

Well, as I've noticed many times before, and as the hyperfine above shows, the actual startup cost of perl itself is not bad at all (a few msec). For me it's only these three modules that really bite (in particular Pod::Usage, unused, takes 50msec). I had no problem with, for example, Time::HiRes, Fcntl, or Sys::Hostname. In my case, I think it makes sense to replace the slow modules (though I'm still surprised they are that slow). I've tried pp to create an executable (which seems to be a self-extracting zip) and it ran about three times slower.

G'day almr,

I made verbatim copies of your four scripts and ran them using time (I don't have hyperfine). I performed multiple runs on each; I got results that were of the same order of magnitude as yours. So, there's nothing problematic with your system in this regard.

I see some workarounds have been suggested. I use the three modules you tested in most of my $work scripts; I've never had any comments about slowness. I don't imagine any of your users will complain that a script took 100ms to start running. :-)

You'll no doubt be loading additional modules which will increase the startup time. Keep an eye on what you're importing.

# Import nothing -- fastest but requires additional coding
use Some::Module ();
...
Some::Module::some_function();
Some::Module::other_function();

# Import just the parts you intend to use -- still fast; less coding
use Some::Module qw{some_function other_function};
...
some_function();
other_function();

# Import everything -- could be very slow
use Some::Module;
...
any_function();
[download]

If you're really concerned about startup speeds, put something like this at the start of your script:

BEGIN { print "Loading app (could take a second or two) ...\n"; }
[download]

Then, when it only takes 100ms or so, your users should be very pleased.

Thanks for taking a look. For a standalone "application", 100msec for sure doesn't matter. However, if (1) I'm calling several perl scripts inside bashrc, or (2) a script is invoked after every command (PROMPT_COMMAND in bash) or (3) a script runs in an editor on every keystroke (see the vim-like editor Kakoune), those 100msec add up. 10 scripts taking 100msec each result in a 1sec delay before being able to type anything, which is of course unacceptable.

I really wonder why such a program would need the full option processing powers of Getopt::Long, if at all.

Options are most useful for programs that are used for several related but different actions. In particular cases 2 and 3 above I would stick to a dedicated program.

Also, perl -s is even faster than Getopt::Std.