Re: removeheaders

> I don't know if performance is at all a concern with this 
> small script, but in its current state it is probably running 
> 3 times slower than it needs to be. It compares the line to 
> three regular expressions, even though only one should ever 
> match. The expressions should also be ordered such that the 
> most likely ones are tried first.
> 
> The diff below corrects these issues. I've only tested it 
> with data that matches the first expression.
> 
> Also, in this line:
> 
>   while (defined($ThisLine = <STDIN>)) {
> 
> is defined() doing anything useful? Even a blank line, due to 
> the newline, will still return true.
> 
>   -Tom
> 


Tom,

I have some similar mods too.  Logwatch's performance has not been a large
consideration it seems.  The biggest performance busters in my opinion are:

1) copying log files to the temp directory (this is huge for large email
installations).  This precludes using logwatch as a general command-line
reporter (it takes just too long to copy an archive of 100meg email log
files; my postscript filter runs in seconds on large files when run
standalone, but when run via logwatch, can take minutes).

2) needless use of pipelining to perform basic filtering.  An original goal
of this project was to allow any scripting language or utility to act as a
pre-filter.  Simple filtering scripts like removeheaders need only be a
table of RE's loaded in by the service filter, rather than chained via
pipelines.  I think its time to just accept the fact that logwatch is
written in perl, uses perl filters and services, and drop the any-scripting
language goal.

I've been contemplating eliminating these two issues.

MrC