Re: Blue (or was it yellow?) GNUS suggestions

[Lars Magne Ingebrigtsen <larsi@ifi.uio.no>]

Sudish Joseph <sudish@vnet.ibm.com> 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."