Answer.

Perl is a dynamically typed and highly flexible language, which often leads to implicit performance costs when misused. Performance optimization is an integral part of maintaining medium and large scripts.

Background

From the very beginning, Perl focused on rapid prototyping and quick library integration. Real optimization came years later, with the advent of profiling modules (Devel::DProf, NYTProf), allocation analysis, and the introduction of established best practices.

Problem

Major bottlenecks arise from uncontrolled growth of structures, unnecessary allocations, frequent data copying, and non-obvious aspects of how the Perl interpreter works — for example, incorrect use of global variables and inefficient regular expressions.

Solution

Profiling the script using Devel::NYTProf. Run: perl -d:NYTProf script.pl, then analyze reports through nytprofhtml
Using built-in functions in the context appropriate for the task (for example, avoid map/grep with large anonymous functions when a regular loop can be used)
Optimizing memory usage — using references instead of copies, avoiding autovivification of large structures, explicitly destroying large arrays through undef

Code example: — comparing inline map versus a simple loop:

my @data = (1..1_000_000);
my @result = map { $_ * 2 } @data; # potentially slower with complex computations
# vs
my @result;
foreach (@data) {
    push @result, $_ * 2;
}

Key Features:

Accurate usage of context — choose loop or map/grep based on the load
Avoid global variables where lexical variables can be used
Frequent profiling and refactoring of "bottlenecks" based on report results

Trap Questions.

Is using map always faster than foreach?

No. For simple manipulations on short arrays, there is little difference, but complex expressions or working with large arrays can slow down due to temporary lists created by map. In foreach, memory can be controlled manually.

Does autovivification affect performance?

Yes, especially when randomly creating large nested structures. Automatic creation of new levels can consume memory very quickly if an uninitialized hash is accessed deep in the structure.

Is it necessary to declare variables with my in advance for speedup?

Yes, but not always for the purpose of speeding up — scope-local variables tend to be accessed faster by Perl than global variables, however, the actual gain depends on the program's size and the number of accesses.

Example:

my $sum = 0;
foreach my $x (@big_array) {
    $sum += $x;
}

Common Mistakes and Anti-Patterns

Excessive or unaware use of global data
Copying large arrays instead of operating by reference
Using heavy regular expressions when simple comparisons would suffice
Not using profilers to analyze the script

Real Life Example

Negative Case

In a large ETL script, logs are processed using map over millions of records with nested regular expressions. The script consumes memory and goes into swap after 20 minutes of execution.

Pros:

Minimal code, easy to write and change

Cons:

The script does not work in production, tremendous memory consumption
Scaling difficulties

Positive Case

Profiling was conducted, explicit loops were added, regular expressions were broken down into stages, and all large arrays were reworked to use references. The script's runtime was halved, and memory consumption decreased tenfold.