From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen)
Subject: Re: Group sorting
Date: 13 Dec 1995 18:30:39 +0100 [thread overview]
Message-ID: <w8sd99syips.fsf@gymir.ifi.uio.no> (raw)
In-Reply-To: dreschs@mpd.tandem.com's message of 12 Dec 1995 16:33:09 -0600
dreschs@mpd.tandem.com (Sten Drescher) writes:
> 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))))
>
> 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!
This lambda form would be given as an argument to the `sort' function,
so this is something that compares two groups. The names of the
functions are misnomers; they should be called `gnus-group-unread-<'
and `gnus-group-level-<'.
> 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.
Yes; that's what the lambda form above does. Just read it very
slowly. :-)
> This is a _significant_ difference in sort time, as only a small
> percentage of groups will have identical unread counts.
I have done no measurements. With this scheme we would have an
uncompiled lambda form (with ~1.7 funcalls) that would be executed
O(n*log(n)) times. Sorting twice (the normal way) would execute a
compiled function (with 0 funcalls) O(2*n*log(n)) times. Anybody want
to benchmark it?
> 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.
Fortunately Emacs `sort' isn't a bubble sort. (What is it, though?
Fastsort?)
--
Home is where the cat is.
next prev parent reply other threads:[~1995-12-13 17:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1995-12-05 17:31 Sten Drescher
1995-12-06 5:05 ` Lars Magne Ingebrigtsen
1995-12-08 17:32 ` Sten Drescher
1995-12-10 15:16 ` Lars Magne Ingebrigtsen
1995-12-11 16:37 ` Sten Drescher
1995-12-12 20:59 ` Lars Magne Ingebrigtsen
1995-12-12 22:33 ` Sten Drescher
1995-12-13 17:30 ` Lars Magne Ingebrigtsen [this message]
1995-12-14 15:56 ` Hallvard B Furuseth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=w8sd99syips.fsf@gymir.ifi.uio.no \
--to=larsi@ifi.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).