P
PerlFAQ Server
This is an excerpt from the latest version perlfaq3.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .
--------------------------------------------------------------------
3.15: How can I make my Perl program run faster?
The best way to do this is to come up with a better algorithm. This can
often make a dramatic difference. Jon Bentley's book *Programming
Pearls* (that's not a misspelling!) has some good tips on optimization,
too. Advice on benchmarking boils down to: benchmark and profile to make
sure you're optimizing the right part, look for better algorithms
instead of microtuning your code, and when all else fails consider just
buying faster hardware. You will probably want to read the answer to the
earlier question "How do I profile my Perl programs?" if you haven't
done so already.
A different approach is to autoload seldom-used Perl code. See the
AutoSplit and AutoLoader modules in the standard distribution for that.
Or you could locate the bottleneck and think about writing just that
part in C, the way we used to take bottlenecks in C code and write them
in assembler. Similar to rewriting in C, modules that have critical
sections can be written in C (for instance, the PDL module from CPAN).
If you're currently linking your perl executable to a shared *libc.so*,
you can often gain a 10-25% performance benefit by rebuilding it to link
with a static libc.a instead. This will make a bigger perl executable,
but your Perl programs (and programmers) may thank you for it. See the
INSTALL file in the source distribution for more information.
The undump program was an ancient attempt to speed up Perl program by
storing the already-compiled form to disk. This is no longer a viable
option, as it only worked on a few architectures, and wasn't a good
solution anyway.
--------------------------------------------------------------------
The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.
If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .
--------------------------------------------------------------------
3.15: How can I make my Perl program run faster?
The best way to do this is to come up with a better algorithm. This can
often make a dramatic difference. Jon Bentley's book *Programming
Pearls* (that's not a misspelling!) has some good tips on optimization,
too. Advice on benchmarking boils down to: benchmark and profile to make
sure you're optimizing the right part, look for better algorithms
instead of microtuning your code, and when all else fails consider just
buying faster hardware. You will probably want to read the answer to the
earlier question "How do I profile my Perl programs?" if you haven't
done so already.
A different approach is to autoload seldom-used Perl code. See the
AutoSplit and AutoLoader modules in the standard distribution for that.
Or you could locate the bottleneck and think about writing just that
part in C, the way we used to take bottlenecks in C code and write them
in assembler. Similar to rewriting in C, modules that have critical
sections can be written in C (for instance, the PDL module from CPAN).
If you're currently linking your perl executable to a shared *libc.so*,
you can often gain a 10-25% performance benefit by rebuilding it to link
with a static libc.a instead. This will make a bigger perl executable,
but your Perl programs (and programmers) may thank you for it. See the
INSTALL file in the source distribution for more information.
The undump program was an ancient attempt to speed up Perl program by
storing the already-compiled form to disk. This is no longer a viable
option, as it only worked on a few architectures, and wasn't a good
solution anyway.
--------------------------------------------------------------------
The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.
If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.