On 08 Dec 1997 11:08:35 +0200, <jari(_dot_)aalto(_at_)poboxes(_dot_)com> wrote:
Sun 97-12-07 Stan Ryckman <stanr(_at_)sunspot(_dot_)tiac(_dot_)net>
list.procmail
| Comparing byte sizes on disk means nothing here... these things
| may or may not have been stripped. Any symbol tables included
| in the byte counts you see above won't affect process start-up time.
sed: 237248 + 16992 + 56252 = 310492
grep: 221591 + 16176 + 53816 = 291583
perl4: 502220 + 36044 + 65632 = 603896
What should we look for if we were to compare performances?
A slimmer grep? In the end, for practical purposes, the file size
isn't really important, as long as you realize that a trivial perl
program can probably be implemented as a trivial awk program which
takes less time to load even if the Perl implementation might be more
efficient (because if your typical data is a message of twenty to
fifty lines, the actual performance of the program is not very
important, compared to the load time).
Basic intuition says that because grep is simpler than awk, it's
probably a smaller binary and better suited to the task at hand if it
can be done in grep. Intuition often fails when you have mysteriously
"optimized" greps which perform badly on your type of input, etc, but
this is already fairly beyond the scope of any Procmail discussion.
When it really matters, you should test and profile. It would
probably be a good idea to test from within a Procmail script over a
folder of saved messages, because that way, you get real data and a
better picture of how your grep/sed/awk/perl behaves in a Procmailish
setting (one process per message, typically short messages that might,
for example, typically never match what you're grepping for).
/* era */
--
Paparazzi of the Net: No matter what you do to protect your privacy,
they'll hunt you down and spam you. <http://www.iki.fi/~era/spam/>