From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9315 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.gnus.general Subject: Re: Quicker exit and re-enter of large groups Date: 08 Jan 1997 13:12:16 -0800 Sender: raeburn@cygnus.com Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035149359 17732 80.91.224.250 (20 Oct 2002 21:29:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:29:19 +0000 (UTC) Cc: Wesley.Hardaker@sphys.unil.ch, ding@ifi.uio.no Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.4/8.8.4) with SMTP id NAA03966 for ; Wed, 8 Jan 1997 13:22:37 -0800 Original-Received: from cygnus.com (cygnus.com [205.180.230.20]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 8 Jan 1997 22:12:37 +0100 Original-Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id NAA16106; Wed, 8 Jan 1997 13:12:26 -0800 Original-Received: from kr-laptop.cygnus.com ([205.180.230.200]) by tweedledumb.cygnus.com (4.1/4.7) id AA15542; Wed, 8 Jan 97 16:12:19 EST Original-Received: (from raeburn@localhost) by kr-laptop.cygnus.com (8.8.3/8.8.3) id NAA29920; Wed, 8 Jan 1997 13:12:18 -0800 Original-To: Kai Grossjohann In-Reply-To: Kai Grossjohann's message of 08 Jan 1997 17:39:44 +0100 Original-Lines: 40 X-Mailer: Red Gnus v0.76/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:9315 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9315 Kai Grossjohann writes: > Well, suppose there's just one new message, then surely it can be > inserted in $O(n)$ time, whereas sorting all messages needs $O(n \log > n)$ time, no? You might need to merge and/or reorder threads, though. > The main time killer (at least for me, I sort messages by number and > use threading but no other sorting -- no scoring or suchlike) is > summary buffer generation which takes the most time. Thus, having to > generate only a few lines and just sticking them in at the right > positions would be a huge improvement. I'm talking about groups with > several thousands of (ticked) messages. I do likewise. Last time I did some profiling, gnus-dd-mmm took a big chunk of that time -- nearly a third. It's called for every message. Can we speed it up somehow? Or, more to the point, cut the cost of a large number of invocations, perhaps with some sort of caching? I've still got code around for caching "fuzzy simplified" subjects to speed up kill-same-subject and such operations, by doing caching the first time the operation is done on an article, increasing its cost a bit, and bypassing all the regexp code when the cache is already primed, greatly cutting the cost on later uses. My current version operates by adding one field to the mail-header structure for Gnus to store information, and a new obarray for each group. Perhaps we could extend that to store parsed-time info for each article, and preserve the info across two accesses to the group? Rebuilding the summary buffer would still take time, but less than it does now (at least, after the first time for the group). (Lars had said long ago he'd include this code or something like it in Red Gnus, but I think it fell off the tail end of his to-do list. Or maybe I get a low score these days because of rants about multi- threaded emacs and stuff. :-) If we had a .overview.el file, maybe we could cache some of this data long-term for nnml....