Spend CPU time running programs, not recompiling them. As nice as it is to be able to type and run a Perl program, compiled programs sometimes have a few advantages. Quickly running processes might spend most of their time launching, not running. If you have a program you might want to run all the time, but it takes significant time to load the appropriate modules and get ready to run and you just can't spare that time on something that should execute immediately and get out of the way or that might have to run dozens of times per second under high load, trade a little memory for speed with PPerl. The HackMatt Sergeant's PPerl module provides a mod_perl-like environment for normal Perl programs. A well-written program can run under PPerl with no modifications. Suppose you use Chia-liang Kao's amazingly useful SVK distributed revision control system, written in Perl.[17] You're continually making lots of little checkins, and you've started to notice a bit of a lag as launching the program continually recompiles a handful of complex modules.
Make a copy of the svk program in your path where your shell will find it before the system version. Edit the file and change the first line from: #!/usr/bin/perl -w ... to: #!/usr/bin/pperl -w That's it! Running the HackThe first time you launch svk, it will take just about as long as normal. Subsequent launches will run much more quickly, as PPerl reuses the launched processavoiding the repeated hit of compilation. This works well for other processes toomail filters written with Mail::Audit or Mail::Filter, SpamAssassin, and any Perl program that can run multiple times idempotently but usually takes little time to run. Hacking the HackAs an administrator, to make a persistent svk to share between every developer on the box, create an alias (or equivalent shell script) to launch svk with the --anyuser flag: alias svk='/usr/bin/pperl -- --anyuser /usr/bin/svk' Other useful flags include --prefork to tune the number of persistent processes to launch and --maxclients to set the maximum number of requests any child will serve before exiting. (This helps keep down memory usage, as multiple requests unshare more and more pages.)
|