Re: Slow Access from Gnus

[Sven Joachim <svenjoac@gmx.de>]

On 2008-04-04 21:54 +0200, Reiner Steib wrote:

> On Fri, Apr 04 2008, Jake Colman wrote:
>
>> WOW!  What a difference!  My prior setting for
>> 'gnus-fetch-old-headers' was t.  I set it to 500 and I now enter the
>> group virtually instantaneously.  Is there any practical downside to
>> specifying a number instead of 't'?
>
> You might not see old posting in the threads...
>
> ,----[ (info "(gnus)Filling In Threads") ]
> | `gnus-fetch-old-headers'
> |      If non-`nil', Gnus will attempt to build old threads by fetching
> |      more old headers--headers to articles marked as read.  If you would
> |      like to display as few summary lines as possible, but still
> |      connect as many loose threads as possible, you should set this
> |      variable to `some' or a number.  If you set it to a number, no
> |      more than that number of extra old headers will be fetched.  In
> |      either case, fetching old headers only works if the back end you
> |      are using carries overview files--this would normally be `nntp',
> |      `nnspool', `nnml', and `nnmaildir'.  Also remember that if the
> |      root of the thread has been expired by the server, there's not
> |      much Gnus can do about that.
> | 
> |      This variable can also be set to `invisible'.  This won't have any
> |      visible effects, but is useful if you use the `A T' command a lot
> |      (*note Finding the Parent::).
> `----
>
>> What setting do _you_ use?
>
> I've set it to t, but I fetch all newsgroups groups from my local
> leafnode server, which does expire Gmane groups, so I don't experience
> the slowness.  Maybe we should warn about this setting when using
> news.gmane.org.

Seems like a good idea, see below.

>  Do others see the slow access on Gmane with as well
> with `gnus-fetch-old-headers' set to t?

I just tried with gmane.linux.debian.devel.bugs.general (HUGE!), where I
have two dozen ticked articles.  After ~1 minute Emacs still was
displaying something like "nntp read: 92167k" (yes, ca. 90 Megabyte!),
then I got tired and typed C-g.  Fortunately, memory footprint dropped
to a reasonable level afterwards.

Sven