Performance Problems Plague Perl on Red Hat
A major problem with the officially distributed version of Perl on Red Hat Enterprise Linux has led to a firestorm of complaints among developers. The problem, which also manifests itself on some versions of the Fedora and CentOS Linux distributions, means that some programs will take more than 100 (yes, one hundred) times longer to execute under Red Hat than other distributions. A Red Hat engineer has indicated that it will fix the problem in its next release (i.e., Red Hat Enterprise 5.3), but has not said when that update will arrive.
Perl, one of the best-known and most popular open-source "scripting" languages, has long been popular among Web developers. Its popularity in the early days of the Web led it to be dubbed "the duct tape of the Internet." Perl's particular strengths -- text processing, network programming, and relational database access -- coupled with rapid coding and speedy execution, made it a natural fit for reporting, database, and Web applications. Even today, many large companies, from Amazon to Goldman Sachs, use Perl extensively in their back-end operations.
It thus comes as a surprise to discover that the latest version of Red Hat Enterprise Linux includes a version of Perl that runs slowly. This problem has been noted in Red Hat's bug tracker for some time, with the first mention occurring in November 2007. The problem appears to be specific to Red Hat's compliation and distribution of Perl, rather than a particular Perl version or a specific module. Running the same program, with the same version of Perl, on FreeBSD or even on Red Hat Enterprise version 4, apparently results in a speedup of nearly 100 times.
The problem appears to stem from a combination of the "bless" function, coupled with the "overload" programming directive. As this author points out, this combination occurs in many publicly distributed Perl modules. This means that even if a program doesn't use "bless" and "overload", a module that it includes might use them, thus causing the problem even in seemingly unaffected programs.