in reply to slow startup for some common modules? (autodie, Pod::Usage, Getopt::Long))

Perl startup is "slow" by some measures.

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)

Cheers Rolf
(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
Wikisyntax for the Monastery

  • Comment on Re: slow startup for some common modules? (autodie, Pod::Usage, Getopt::Long))

Replies are listed 'Best First'.
Re^2: slow startup for some common modules? (autodie, Pod::Usage, Getopt::Long))
by almr (Beadle) on Dec 27, 2022 at 22:37 UTC
    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.