M-x gnus-filter-mail-at-warp-10 (was: Re: Pre-Processed maiil splitting under Gnus?)

[Asymptotically Approaching Relaxation <feoh@cosmic.com>]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> 
> > Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:
> > 
> >   > I'm seeing a total performance turnaround once I re-wrote my .gnus
> >   > file and minimized the length and complexity of the regexes I'm
> >   > filtering on.
> > 
> > Ah.  Why didn't I think of this?  Since the Day of the
> > Posixification of Regexes, regex matching has been rather slower for
> > a number of regexes; and I'm not sure whether the fact that they're
> > posixly correct now should be considered a Good Thing...
> 
> Strange.  Two remarks, though (none of which is meant to argue with
> you):
> 
> 1) As demonstrated by Tom Lord, GNU regex (which both Emacsen use) is
>    still not POSIX.
> 
> 2) Why are there, at least in XEmacs, two sets of functions, posix-
>    regexp functions, and "normal" regexp functions?  Also, the
>    internal code has various posix-p flags that apparently specify
>    whether POSIX behaviour is desired.  I though the reason for
>    duplicate functionality was to gain speed in the non-POSIX (the
>    more usual) case.


Hrrm.  I'm not sure whether or not XEmacs' regexps Posixness or lack
thereof is the determining faactor here.  I suspect a dash of clue and 
a *MUCH* less complex string to parse per each filter are the cause.

Here's the first bits of my nnmail-split-methods, old and new:

OLD: <Note: There are several syntactically legal but obviously broken
      expressions here, this didn't help in any case :)>

(setq nnmail-split-methods
	'(("mail.imagine" ".*owner-imagine@MAELSTROM\.STJOHNS\.EDU")
	("mail.mesa" "Return-Path:.*mesa.*.BR.*")
	("mail.kaffe" "Sender:.*kaffe@w3\.org")
	("mail.0xdeadbeef" ".*0xdeadbeef@substance\.abuse\.blackdown\.org")
	("mail.0xdeadbeef" "To:.*0xdeadbeef@substance.abuse.blackdown.org")
	("mail.linux-kernel" "linux-kernel@vger\.rutgers\.edu")
	("mail.linux-smp" "linux-smp@vger\.rutgers\.edu")
	("mail.linux-net" "linux-net@vger\.rutgers\.edu")
	("mail.linux-gcc" "linux-gcc@vger\.rutgers\.edu")
	("mail.linux-svgalib" "linux-svgalib@vger\.rutgers\.edu")
	("mail.linux-tape" "linux-tape@vger\.rutgers\.edu")
	("mail.linux-scsi" "linux-scsi@vger\.rutgers\.edu")

...


NEW: 
(setq nnmail-split-methods
	("mail.imagine" "owner-imagine@")
	("mail.0xdeadbeef" "0xdeadbeef@")
	("mail.gnus" "ding@gnus\.org")
	("mail.gimp" "gimp-.+@")
	("mail.hwg-languages" "hwg-languages@")
	("mail.hwg-critique" "hwg-critique@")
	("mail.hwg-software" "hwg-software@")
	("mail.squeak" "squeak@cs\.uiuc\.edu")
	("mail.boston-pm" "boston-pm@")
	("mail.perldl" "perldl@")
	("mail.freshmeat" "freshmeat-news@")

...

You get the idea.

To at least somewhat quantify my performance boost, a mail spool of
approx. 100 messages used to take on the order of a minute plus some
slop.  The same spool now filters in a little under 3 seconds :)

Yay.  I don't have to mess with procmail :)

-Chris
(I personally still favor pre versus post processing, but the pain is
gone so I'll move on to the next egregious wound and call it a win :)
____________________________________________________________________
|Chris Patti|ICQ#16333120|feoh@cosmic.com|Home #:(617)625-3194|JAPH|
|"I have opposable thumbs, and I can buy a rifle.  I don't need to |
| run from anything." -Todd Finney				   |