I developed my own module (package) for example MyUtils.pm.
That is a file located on same folder than the main.cgi that use it. Then I use the module with use MyModule;
I think that is a bit slow. Or suppose there's a better way.
Is it possible to "compile the module" and include it in perl core or something like that?
If yes, I think it will load and run "faster".
Don't worry too much about it. The overhead of loading a Perl module is quite low.
If your application is getting enough traffic that this overhead does become significant, it's time to stop using CGI — the overhead of starting the Perl interpreter becomes a problem on its own. Consider switching your site to use something like FastCGI (with CGI::Fast or Plack::Handler::FCGI), or the mod_perl Apache module (possibly in conjunction with ModPerl::Registry to run CGI scripts directly, or with Plack::Handler::Apache2). Any of these will allow multiple consecutive requests to be handled by a single process, bypassing the module loading process entirely.
I think you are looking for B::Bytecode.
DESCRIPTION
Compiles a Perl script into a bytecode format that could be loaded
later by the ByteLoader module and executed as a regular Perl script.
This saves time for the optree parsing and compilation and space for
the sourcecode in memory.
Related
I have a perl package called mypackage.pm (that i have on disk)
I have a script called test.pl
Inside my test.pl I have the following statement
use mypackage;
Now why, when I make changes inside mypackage, are those changes are NOT reflected when running my test.pl script?
No.
When you start a Perl program, the perl compiler will read all the modules referenced in the program from disk, compile them and store the resulting opcode in memory. It will also remember which files it has already read (in %INC) so it does not read them again.
There is a difference to when those files are read, but they are likely not significant here. If you use a module, it will be loaded at compile time, as in when the program starts. If you require a module, that can be inside of conditionals, and the file will be read when that code is executed at run time. That might be while the program starts up, or way later, or even never. Perl then switches back to compile time for that file to compile it, and then returns to run time.
If you want to re-read a module that you use, you will typically have to restart your program.
Having said that, there are some black magic implementations that allow you to re-load a module that has changed on disk. Unless you are building a daemon with insane start-up time and high throughput there is probably no need to use that.
One of these modules is Module::Reload. Its been around for a while and has recently seen some changes. Its See Also section points to further implementations, namely Module::Reload::Selective and the again pragma.
I have used neither of these and can't say if they work or how.
This question already has an answer here:
Using Perl modules vs. using system() calls
(1 answer)
Closed 9 years ago.
On occasion I see people calling the system grep from Perl (and other scripting languages for that matter) instead of using the built-in language facilities/libraries to parse files. I would like to encourage people to use the built-in facilities and I want to solicit some reasons as to why it is good practice to use the built-in tools. I can think of some such as
Using libraries/language facilities is faster. Performance suffers due to the overhead of executing external commands.
Sticking to language facilities is more portable.
any other reasons?
On the other side of the coin, are there ever reasons to favour using system commands instead of the built-in language facilities? On that note, if a Perl script is basically only calling external commands (e.g. custom utilities without libraries), might it be better just to make a shell script of it?
Actually, when it matters, a specialized tool can be faster.
The real gains of keeping the work in Perl are:
Portability (even between machines with the same OS).
Ease of error detection.
Flexibility in handling of errors.
Greater customizability/flexibility.
Fewer "moving parts". (Are you sure you correctly escaped everything and setup the environment correctly?)
Less expertise needed. (You don't need to know both Perl and the external tools (and their ports) to code and maintain the program.)
On that note, if a Perl script is basically only calling external commands (e.g. custom utilities without libraries), might it be better just to make a shell script of it?
Possibly. You can configure some shells to exit if any program returns an unsuccessful error code. This can make some scripts quite robust. For example, I have a couple of bash scripts featuring the line
trap 'e=$? ; echo "Error." ; exit $e' ERR
"On the other side of the coin, are there ever reasons to favour using system commands instead of the built-in language facilities? On that note, if a Perl script is basically only calling external commands (e.g. custom utilities without libraries), might it be better just to make a shell script of it?"
Risking the wrath of Perl hardliners here. But for me there is an easy reason to use system grep instead of perl grep: I know its syntax.
Same reason to use a Perl script instead of a bash script: I know how to do stuff in Perl and never bothered with bash script syntax.
And as we are talking scripts here, my main concern is getting it done fast and reliable (and readable). At work i do not have to bother with portability as all production is done on the very same system, down to the same software versions of everything for the whole product lifespan.
At home i do not have to care about lifetime or whatever either as the script most likely is single-purpose.
And in neither case i care about performance or software security as i would be using C++ or something else for commercial software or in time or memory limited scenarios.
edit: Not saying these reasons would apply to anyone, or even anyone else. But while in reality i know how to use Perls grep, i really have no idea how to write a bash script and most likely never will. Just putting a few lines in Perl is always faster for me.
Using external tools lead to do more error.
Moreover you have you to parse the results (if any) of the external command, which is an other source of error.
No need to say that it is bad in terms of security.
I am trying to find some online tool for compressing and optimizing my perl. Is there any benefit to removal of (at a minimum) whitespace and comments from server side cgi?
Perl source undergoes a compilation phase, it is not directly interpreted. Perl code is executed at the server, not delivered to the client. Unlike JavaScript, there is no benefit from minimisation.
If you want to optimise, measure first where the bottle-neck is. I presume that switching from CGI to a persistent technology will give you a big pay-off.
Related:
How can I compile my Perl script so to reduce startup time?
How can I reduce Perl CGI script start-up time?
Edit:
You mention in a comment that you deploy on Apache httpd. To reduce start-up time without changing existing code, install mod_perl2 and run your CGI programs with the perl-script handler. In the long term, switch over your code base from CGI to PSGI and deploy on Plack::Handler::Apache2, or preferably, if you also have an FastCGI adapter for the web server, Plack::Handler::Net::FastCGI.
Perltidy is a free pretty-printer with a lot of options. Some of them might do what you want in some way, remove whitespace for instance. It's not a minifier, but good to know nevertheless, I'd recommend to add it to your toolchest
The docs I find around the ’net and the book I have, Perl Testing, either say or suggest that unit-testing for Perl is usually done when creating modules.
Is this true? Is there no way to unit-test actual programs using Test::More and cousins?
Of course you can test scripts using Test::More. It's just harder, because most scripts would need to be run as a separate process from which you capture the output, and then test it against expected output.
This is why modulinos (see chapter 17 in: brian d foy, Mastering Perl, second edition, O'Reilly, 2014) were developed. A modulino is a script that can also be used as a module. This makes it easier to test, as you can load the modulino into your test script and then test its functions like you would a regular module.
The key feature of a modulino is this:
#! /usr/bin/perl
package App::MyName; # put it in a package
run() unless caller; # Run program unless loaded as a module
sub run {
... # your program here
}
The function doesn't have to be called run; you could use main if you're a C programmer. You'd also normally have additional subroutines that run calls as needed.
Then your test scripts can use require "path/to/script" to load your modulino and exercise its functions. Since many scripts involve writing output, and it's often easier to print as you go instead of doing print sub_that_returns_big_string(), you may find Test::Output useful.
It's not an easiest way to test your code, but you can test the script directly. You can run the script with specific parameters using system (or better IPC::Run3), capture output and compare it with expected result.
But this will be a top level test. It'll be hard to tell which part of your code caused problem.
Unit-tests are used to test individual modules. This makes it easier to see where the problem came from. Also testing functions individually is much easier, because you only need to think about what can happen in smaller piece of code.
The way of testing is depend on your project size. You can, of cause, put everything into single file, but putting your code into module (or even splitting it into different modules) will give you benefits in future: code can be easier reused and tested.
What is the difference between library files and modules in Perl?
It's all Perl code to perl. All distinctions are purely idiomatic.
Perl code meant for inclusion that uses a package directive:
Called "module".
Usually has the extension .pm. Must have this extension for use to find them.
Should always be loaded with require, possibly via use.
Must therefore return a true value.
More modular, better supported by CPAN.
Perl code meant for inclusion that doesn't use a package directive:
Called "library". (At least historically. These days, "library" might also be used to refer to a module or distribution.)
Usually has the extension .pl.
Should always be loaded with do.
Pollutes the caller's namespace.
Usually indicative of a substandard design. Avoid these!
Perl code meant for direct execution by interpreter:
Called "script".
Usually has the extension .pl, or none at all.
Will probably start with a shebang (#!) line so they can be started without specifying perl.
Library files (I'm assuming you mean require 'foo.pl' stuff here) are an obsolete (pre-Perl 5) form of external module. For the most part, you shouldn't need to care any more, although there are still some Perl 4 installations around and therefore still some Perl code that remains backward compatible with them (and there's some code that's simply never been updated and still loads getcwd.pl etc.).
Nothing. They are both files that contain Perl code. Here are some of the possible circumstantial differences, though.
A perl executable is more likely to have a #!/bin/perl shbang.
Old .pl Perl libraries (hence the 'p' + 'l') are more likely to expect to be required than .pm modules.
Perl 5 style (.pm) modules are more likely to use Exporter -- although even newer module eschew exporting anything.