Officially, Perl stands for Practical Extraction and Report Language, except when it doesn't. Perl was originally a language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It quickly became a good language for many system management tasks. Over the years, Perl has grown into a general-purpose programming language. It's widely used for everything from quick "one-liners" to full-scale application development.

The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). It combines (in the author's opinion, anyway) some of the best features of sed, awk, and sh, making it familiar and easy to use for Unix users to whip up quick solutions to annoying problems. Its general-purpose programming facilities support procedural, functional, and object-oriented programming paradigms, making Perl a comfortable language for the long haul on major projects, whatever your bent.

Perl's roots in text processing haven't been forgotten over the years. It still boasts some of the most powerful regular expressions to be found anywhere, and its support for Unicode text is world-class. It handles all kinds of structured text, too, through an extensive collection of extensions. Those libraries, collected in the CPAN, provide ready-made solutions to an astounding array of problems. When they haven't set the standard themselves, they steal from the best — just like Perl itself.

How can we get started with Perl?

If you are using Unix / Linux, chances are good that Perl is already installed. If not, you can use the appropriate package manager for your operating system to install Perl. If you use Windows, you can google Perl and download the one from Active State.

When you use a package such as Some::Package, Perl looks for a file Some/Package.pm in the current directory. If this file doesn't exist, it looks for it in the system's global directory (like c:/perl/lib) and in the global @INC array.

How can we cause Perl to look for module in our own user-defined location?

It is a good idea to save your application packages to a directory like lib and add that directory to the list of namespace roots using use lib 'my/root/path':

use lib 'lib'; # Add the sub-directory 'lib' to the namespace root @INC
use Some::Package; # Walks through @INC to find the package file

How can a module export its subroutines and variables into the global namespace?

This is not recommended, unless you have a really good reason. In order to export symbols, inherit from the Exporter class and fill the @EXPORT array with the symbols you'd like to export:

The above code exports the foo and bar function by default. It might be a good idea to leave it up to the requiring package to decide which symbols get exported into its namespace. In that case you simply use the @EXPORT_OK array instead or @EXPORT:

Locate bottlenecks and think about writing those parts in C or assembly. See Inline module.

If your perl executable is currently linked to libc.so, you can often gain 10-25% performance benefit by rebuilding it to link to the static libc.a instead. This make a bigger executable but your perl program may thank you for it. If your server is only for serving mod_perl code, you may want to double check.

Using substr() or vec() to simulate arrays can be highly beneficial.

The standard Tie::SubstrHash module can also help for certain types of data structure.

If you're working with specialist data structures (matrices, for instance) modules that implement these in C may use less memory than equivalent in Perl modules.

Another thing to try is to learn whether your Perl was compiled with the system's malloc or with Perl's builtin malloc. Whichever one it is, try using the other one and see whether this make a difference. You can find out whether you are using perl's malloc by typeing "perl -V:usemymalloc"

Don't read an entire file into memory if you can process it line by line.

Avoid using map and grep on large list.

Avoid unnecessary quotes and stringifications

Avoid stringifying arrays: { local $, = ""; print @big_arrays; }

Pass by reference. Pass arrays and hashes by reference, not by value. It avoids creating a copy of all the contents.

Tie large variables to disk. For big data stores, ones that exceed available memory, consider using one of the DB modules to store it on disk instead of RAM. This will incur a penalty in access time, but that's probably better than causing your hard disk to thrash due to massive swapping.

Don't use English.pm because it export a lot of variables (need verification)