From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4366 Path: main.gmane.org!not-for-mail From: dreschs@mpd.tandem.com (Sten Drescher) Newsgroups: gmane.emacs.gnus.general Subject: Re: Group sorting Date: 12 Dec 1995 16:33:09 -0600 Organization: Tandem Computers Sender: dreschs@mpd.tandem.com Message-ID: <55ivjlud3u.fsf@galil.austnsc.tandem.com> References: <55ka4b8lka.fsf@galil.austnsc.tandem.com> <557n07h36c.fsf@galil.austnsc.tandem.com> <55d99v7e0z.fsf@galil.austnsc.tandem.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1035145122 29349 80.91.224.250 (20 Oct 2002 20:18:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:18:42 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id PAA13871 for ; Tue, 12 Dec 1995 15:08:15 -0800 Original-Received: from galil.austnsc.tandem.com (argyle.mpd.tandem.com [131.124.250.13]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Dec 1995 23:31:36 +0100 Original-Received: (from dreschs@localhost) by galil.austnsc.tandem.com (8.7.1/8.7.1) id QAA11405; Tue, 12 Dec 1995 16:33:12 -0600 (CST) Original-To: ding@ifi.uio.no In-Reply-To: larsi@ifi.uio.no's message of 12 Dec 1995 21:59:56 +0100 Original-Lines: 57 Xref: main.gmane.org gmane.emacs.gnus.general:4366 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4366 larsi@ifi.uio.no (Lars Magne Ingebrigtsen) said: LMI> dreschs@mpd.tandem.com (Sten Drescher) writes: >> (setq gnus-group-sort-function '(gnus-group-sort-by-level >> gnus-group-sort-by-unread)) >> >> This would first do a complete sorting by level, then a complete >> sorting by unread - 2 complete sorts. I'd want it to work in a >> single sort - the sort would compare the unread keys, and _only_ if >> they matched, compare the level keys. LMI> Ok, that would be workable. Gnus could transmogrify that list to LMI> (lambda (g1 g2) LMI> (or (gnus-group-sort-by-unread g1 g2) LMI> (and (not (gnus-group-sort-by-unread g2 g1)) LMI> (gnus-group-sort-by-level g1 g2)))) LMI> and give that as the predicate to sort. Won't this give you the LMI> same results as first using `gnus-group-sort-by-level' as a LMI> predicate and then `gnus-group-sort-by-unread' as a predicate for LMI> sort? LMI> I have no idea whether it will be faster, though... I don't know, because I don't understand the elisp - what is it doing? Is it still sorting the entire list of groups between g1 and g2, or does that fragment just compare two groups? If each gnus-group-sort-by-x sorts a list of groups, then no, it appears that it will be worse, as you are doing three sorts instead of two! As it is now, two entire sorts are done with one key each - every group is sorted by level, then every group is sorted by unread. I'm proposing that one sort be done with two keys - every group is sorted by unread, then ONLY IF the unread counts are equal are the two groups being compared sorted by level. This is a _significant_ difference in sort time, as only a small percentage of groups will have identical unread counts. This difference might be noticable with a small number of groups, but even with only about 2500 groups I can tell the difference between one and two sorts, and I'm dreading seeing even a single sort with the 14,000 groups my ISP carries. Remember, the time for a bubble sort grows as the square of the number of sorted items. However, LMI> (`gnus-group-sort-by-level' should really be called LMI> `gnus-group-level-less' or something since it is a `less' function LMI> and not an actual sorting function...) LMI> -- Home is where the cat is. -- #include /* Sten Drescher */ To get my PGP public key, send me email with your public key and Subject: PGP key exchange Key fingerprint = 90 5F 1D FD A6 7C 84 5E A9 D3 90 16 B2 44 C4 F3