From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6400 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Blue (or was it yellow?) GNUS suggestions Date: 27 May 1996 03:49:57 +0200 Message-ID: References: <199605252131.RAA00636@atreides> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146861 3485 80.91.224.250 (20 Oct 2002 20:47:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:47:41 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id TAA10345 for ; Sun, 26 May 1996 19:16:53 -0700 Original-Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 27 May 1996 03:59:31 +0200 Original-Received: (from larsi@localhost) by eistla.ifi.uio.no ; Mon, 27 May 1996 03:59:30 +0200 Original-To: ding@ifi.uio.no In-Reply-To: Sudish Joseph's message of Sat, 25 May 1996 17:31:54 -0400 Original-Lines: 59 X-Mailer: September Gnus v0.97/Emacs 19.29 Xref: main.gmane.org gmane.emacs.gnus.general:6400 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6400 Sudish Joseph writes: > * Caching the list of newsgroups locally. > Setting gnus-read-active-file to 'some solves the speed problem in the > most common case (startup), but it makes it very painful to subscribe > to new/boring-until-now groups. Setting gnus-save-killed-list to 't > solves this, but makes exit very slow. I guess what I'm asking is if > it's possible to split the killed list from the .eld file, so that > it's not necessary to read and write such a large chunk of data every > session. Viewing it as a reduced (w/o article ranges) local copy of > the active file might be better than just calling it a killed list. > Updating this cache when we see new groups (gnus-check-new-newsgroups > is 'ask-server, of course) would keep things very neat. Well -- whenever new groups arrive, the cache would have to be updated. Which would be just as slow as things are now, more or less. (Most days at least a couple of groups arrive.) > * Defering splitting of mail in nnml groups to group entry. > This isn't related to bandwidth in any way, but I might as well bring > it up here. The actual speed hit in nnml is in the writing of the > articles to individual files, not in the nov file generation. So, > just spooling all articles to one file per nnml group that would be > split into separate files upon group selection would be neat. Sounds like quite a lot of work, and not that much gain, so I don't think I'll write it, at least. > I think this, or having nnfolder with nov, would be a very cool option > for people with NFS mounted home directories. nnfolder+nov would be a possibility, but I'm not sure that would be much of a speedup, really. > * Prefetching of articles in the next group. This is on the Red Gnus todo list. I've written a new implementation of nntp.el which is fully & totally asynchronous, so I think there just might be lots of this sort of thing in Red Gnus. > * Some way to force GNUS to drop all active tcp connections to the > NNTP server and open them anew. This is on the Red Gnus todo list. > * Incremental/asynchronous group entry. By far the most time spent is in actually generating the summary buffer. (Unless you sort by date -- then sorting takes most of the time.) So this would be possible. The thread generation could be put in a daemonic process that would output one thread at a time and let the user read while it's generating. (Hey -- it could even generate the next group while you're reading the current one. :-) It wouldn't actually be that much work either, I think. We'll see. -- "Yes. The journey through the human heart would have to wait until some other time."