Re: reading .overview files takes too long!

Re: reading .overview files takes too long!

[Stainless Steel Rat]

X-Geek-3: GAT d-(++)@ s: a-
	C+(++) US++++$ P++>+++ L>+++ E+++ W++ N+++ K++++ w---$ O?>++ M-$ V-
	PS+ PE Y+(++) PGP++ !t 5++ X? R(+) tv b+++ DI+ D++ G+ e+>++(*) h! r y+
References: <199510260915.CAA15950@mir.cs.washington.edu>
	<199510261440.KAA27436@catfish.lcs.mit.edu>
	<199510261545.IAA04484@meitner.cs.washington.edu>
	<w8szqein1t3.fsf@surt.ifi.uio.no>
	<199510302142.WAA06042@ssv4.dina.kvl.dk>
	<w8sivl3adkt.fsf_-_@surt.ifi.uio.no>
Date: 02 Nov 1995 10:04:12 -0500
In-Reply-To: larsi@ifi.uio.no's message of 02 Nov 1995 04:40:50 +0100
Message-ID: <sr3fc783df.fsf@delphi.ccs.neu.edu>
Lines: 29

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> But the number of threads in a typical group usually is seldom over
LMI> 100, which means that the time saved might be lost in the extra
LMI> overhead... but probably not.

I dunnow about that. I read a bunch of newsgroups that average 150-200
or more messages per day, not to mention my list owner mail groups that
can receive a huge pile of bounce messages on one of the high-traffic
lists I maintain (100 messages per day times three bad addresses equals
a boatload of bounces).

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMJjd5J6VRH7BJMxHAQHo3QP9HW16zcqQaJ5yY+Aw93HqqScRkn+i5cGS
giIAPEANaMME8xl1hCCnQQImZhRWQgw7UVt/FyADXwUw9K1yTglUcpOkaY3vk56P
qDtXRgQHntV71E1oYX7TECiBIPGqfxjqFVfDSV4nyM8a3RRkdrXZUSHxf0QxSs7k
EosOvG6BAoA=
=XHh1
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@ccs.neu.edu>          \ Warning: pregnant women, the elderly, and
PGP Public Key: Ask for one today!  \ children under 10 should avoid prolonged
http://www.ccs.neu.edu/home/ratinox/ \ exposure to Happy Fun Ball.

Re: reading .overview files takes too long!

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@ccs.neu.edu> writes:

> LMI> But the number of threads in a typical group usually is seldom over
> LMI> 100, which means that the time saved might be lost in the extra
> LMI> overhead... but probably not.
> 
> I dunnow about that. I read a bunch of newsgroups that average 150-200
> or more messages per day, not to mention my list owner mail groups that
> can receive a huge pile of bounce messages on one of the high-traffic
> lists I maintain (100 messages per day times three bad addresses equals
> a boatload of bounces).

Yes, but if there are 150-200 articles, there aren't more than 75
threads.  (Sorting is only done on roots.)

-- 
Home is where the cat is.

Re: reading .overview files takes too long!

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> LMI> But `sort-by-date' is (and will always be) very slow,
> 
> It does parse the date header O(N log N) times, and only need to do
> that O(N) times, so it can be made much faster.

That's true.  That would require a slight total rewrite of the thread
sorting functions, though.  

But the number of threads in a typical group usually is seldom over
100, which means that the time saved might be lost in the extra
overhead...  but probably not.

Yikes!  This is `gnus-sortable-date', which is called twice for each
comparison (O(N log N)):

(defun gnus-sortable-date (date)
  "Make sortable string by string-lessp from DATE.
Timezone package is used."
  (let* ((date (timezone-fix-time date nil nil)) ;[Y M D H M S]
	 (year (aref date 0))
	 (month (aref date 1))
	 (day (aref date 2)))
    (timezone-make-sortable-date 
     year month day 
     (timezone-make-time-string
      (aref date 3) (aref date 4) (aref date 5)))))

I think I'll stick by my original statement -- `sort-by-date' will
always be slow.  :-)

-- 
Home is where the cat is.