From: jsparkes@bcars68a.bnr.ca (Jeff Sparkes)
Newsgroups: gnu.emacs.gnus
Subject: Re: Does gnus 3.14 thread better than 3.13?
Date: 2 Sep 92 20:35:41 GMT
Organization: Bell-Northern Research Ltd., Ottawa

In article <JWZ.92Sep2113858@thalidomide.lucid.com> Jamie Zawinski <jwz@lucid.com> writes:
>In article <1992Sep2.155044.5988@sfn.ORG> cliff@sfn.ORG (R. Cliff Young) wrote:
>> 
>> The underlying problem is that only articles in the Subject buffer are
>> available for GNUS to figure out the thread structure.
>
>The reason for this is nowhere near as good as that.  GNUS has enough
>information to properly thread articles whose common parent is not visible
>or has expired, but it doesn't.  The References: field contains a list of
>all of the parents of an article, and this could be used to figure out
>the relationships between two articles which would otherwise be considered
>"roots."
>
>> Unlike trn, it does not maintain a threading database, so it must always
>> thread based on what article headers it requests from the NNTP server.
>
>This is all you ever need.
>
>> If GNUS were to achieve a level of threading sophistication equivalent
>> to trn, it would need to do the following (based upon my personal
>> observations of trn in action):
>> 
>> 1) Maintain a threading database.
>
>No, you don't need to do this.  The only thing that maintaining a threading
>database gets you is efficiency: you don't need to parse the References:
>fields of the headers of the unread articles.  However, GNUS does that now,
>and it's acceptably fast, so the extra complication of a threading database is
>unjustified.  Especially given the other problems they have: they take up a
>huge amount of space, and you generally have to be the news administrator to
>install them.  All of this stuff can be done on the client side, so it should.

It appears that you have a different threshold for acceptable speed.
On my sparcstation 2, it takes over a minute to thread a hundred
articles, which sure feels like an awful long time.  Especially if
you've ever used trn.  Or if you read comp.os.linux.

But it's not gnus' fault.  I did an experiment in which I wrote a
little program to talk to the NNTP server, grab all the headers, and
output the strings in pre-parsed lisp format.  I was surprised to find
that it yielded only about a 25-35% inprovement; most of the delay was
the server nntp grabbing headers.  It seems that speed the HEAD
command in NNTP would have the biggest win.

Geoff Collyer mentioned at Usenix that he may be working on a standard
thread format to be added to NNTP; this can probably be used in the
long run.

In the short run, in some of my spare spare time, I've been trying to
get gnus to understand the trn mthreads database.  There are two
problems that I haven't dealt with yet:

1. mthreads stores a shortened version of the from field.  This would
   badly break BBDB, and other things that do neat things with the
   addresses.
2. the date is stored as a long.  I can't easily turn this back into a
   string inside emacs.  Hell, I can't even represent it properly.
   (There are some hack in lemacs, but I wouldn't call that portable.
   Yet.)



--
--
Jeff Sparkes jsparkes@bnr.ca	Bell-Northern Research, Ottawa (613)765-2503
"For better gas mileage, do not drive with the parking brake on."
  - paraphrased from the owners manual of my Integra.