From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9791 Path: main.gmane.org!not-for-mail From: David Moore Newsgroups: gmane.emacs.gnus.general Subject: Re: nnmail-split-it Date: 03 Feb 1997 20:35:15 -0800 Sender: dmoore@sdnp5.ucsd.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035149761 20563 80.91.224.250 (20 Oct 2002 21:36:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:36:01 +0000 (UTC) Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.5/8.8.5) with SMTP id UAA11440 for ; Mon, 3 Feb 1997 20:49:49 -0800 Original-Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 4 Feb 1997 05:32:29 +0100 Original-Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.5/8.6.9) with SMTP id UAA12867 for ; Mon, 3 Feb 1997 20:32:28 -0800 (PST) Original-Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4) id UAA28707; Mon, 3 Feb 1997 20:35:16 -0800 Original-To: ding@ifi.uio.no X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L Mail-Copies-To: never In-Reply-To: Lars Magne Ingebrigtsen's message of 04 Feb 1997 02:55:34 +0100 Original-Lines: 45 X-Mailer: Gnus v5.4.8/XEmacs 19.15 Xref: main.gmane.org gmane.emacs.gnus.general:9791 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9791 Lars Magne Ingebrigtsen writes: > Paul Franklin writes: > > > Hmm. I wrote some elisp code to do splitting like this. I didn't > > distribute it because: > > > > * I realized that the bottleneck was disk access time (over NFS). > > The box I'm sitting with now is a 486/slow without NFS, and splitting > is kinda slow here as well. Two different costs. There is a per message cost (like NFS and file stating). There is also a per split cost (which is roughly O(n*m) where n is the number of splits, and m is the number of headers in the message). > > It generates a alist of headers, unwrapping lines within headers and > > separating values from duplicate headers with "\n". You then match > > with a header or multiple ones concatenated (very useful, for me at > > least). I never compared them with the default split rules, but I'm > > fairly sure that this code is tight enough that it's very unlikely to > > be a bottleneck. This is similar to what I suggested, but I wasn't going to bother to put the headers into concatenated strings, since that is quite slow itself. But tracking the start/end position of those strings makes doing a buffer regexp search much much faster since it limits the scope of the search. As far as why it's a reverse search. Well, I added the \1 sub ability, and didn't think about the double .* affects with that, probably because I wasn't using it with 'sender', and I think I used `\\w' instead of `.'. I recommend that people try [^ :]* or \\w* instead of .* and see if that helps. I'm not totally sure why Per used a reverse search in the first place, but I left it because most of the "uninteresting" headers are at the beginning (received, etc), and it'll hit the lowest of any multiply matching lines. -- David Moore | Computer Systems Lab __o UCSD Dept. Computer Science - 0114 | Work: (619) 534-8604 _ \<,_ La Jolla, CA 92093-0114 | Fax: (619) 534-1445 (_)/ (_) | In a cloud bones of steel.