From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8491 Path: main.gmane.org!not-for-mail From: David Moore Newsgroups: gmane.emacs.gnus.general Subject: mail fetching speed problems 5.2.25 Date: 25 Oct 1996 14:41:46 -0700 Sender: dmoore@sdnp5.ucsd.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148643 12411 80.91.224.250 (20 Oct 2002 21:17:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:17:23 +0000 (UTC) Return-Path: Original-Received: (qmail 29027 invoked from smtpd); 25 Oct 1996 22:12:14 -0000 Original-Received: from ifi.uio.no (0@129.240.64.2) by deanna.miranova.com with SMTP; 25 Oct 1996 22:12:13 -0000 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 ; Fri, 25 Oct 1996 23:42:35 +0200 Original-Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.2/8.6.9) with SMTP id OAA23664 for ; Fri, 25 Oct 1996 14:42:30 -0700 (PDT) Original-Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4) id OAA27346; Fri, 25 Oct 1996 14:41:47 -0700 Original-To: (ding) GNUS Mailing List Original-Lines: 71 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Xref: main.gmane.org gmane.emacs.gnus.general:8491 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8491 If this has been fixed, please let me know, I'll be upgrading to red gnus this weekend anyways. I've noticed that often pressing 'M-2 g' in the group buffer is pretty speedy at filing all of my new mail and saying that it was done fetching the new mail. But my emacs would then sit looping for another 1-2 minutes. This delay mostly only happens when I really do have new mail. Using elp and the debugger, and peering at the source code, I notice the following problem: *** This is a structural problem with how gnus queries backends for new *** messages, but might be fixable with adding some smarts to *** nnmail-get-active or nnml-request-list. gnus-get-unread-articles calls (gnus-activate-group group 'scan) for every nnml mail group. gnus-activate-group calls nnml-request-group nnml-request-scan calls nnmail-get-new-mail for each of those calls. This means that my new mail is fetched and distributed on the first call, but the system still attempts for each of the following calls. nnmail-get-new-mail calls (nnmail-activate 'nnml) on each of these calls, before it even bothers to see if there was anything in the spool file, which is obviously empty since it was cleared by the first group. nnmail-activate then goes through every group checking the time stamps on the active files. And the second time through it updates the internal active list information for the disk active files which were modifed when the first group caused the spool file to be split. gnus-get-unread-articles also calls gnus-get-unread-articles-in-group for every group. gnus-activate-group _also_ calls gnus-request-group, which hands off to nnml-request-group. nnml-request-group then calls (nnmail-activate 'nnml) on every group The end result here is that for my 104 mail groups: I get 104 calls to several routines which might be reasonable. 208 calls to nnmail-activate. 414 calls to nnmail-get-active. 104 calls to nnmail-get-new-mail. 207 calls to nnml-request-list (which cause half of the calls to nnmail-get-active). I call nnmail-get-active 414 times which parses my entire top level nnml active file 414 times, each time creating a list with 312 elements by use of a complex regexp. And each of these 414 times we through the list in the trash. So to fetch a single new mail message, I generate 129168 con cells in nnmail-get-active alone. Please tell me this is fixed. I suppose a smart thing to do would be to only have nnml-request-list reparse the active file if it's changed since the last time it did so. Of course, it might be nice to change how Gnus talks to it's backends, so that it could basically just activate everything once, then split the new mail up. Then go through and update the unread listings. As it is now, it does that to every group with the same method. -- David Moore | Computer Systems Lab __o UCSD Dept. Computer Science - 0114 | Work: (619) 534-8604 _ \<,_ La Jolla, CA 92093-0114 | Fax: (619) 534-1445 (_)/ (_) | Solo Furnace Creek 508 -- 1996!