From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/81926 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.gnus.general Subject: Re: Excessive nntp reads since today Date: Tue, 12 Jun 2012 18:31:25 +0200 Message-ID: <87aa08big2.fsf@thinkpad.tsdh.de> References: <877gvcd91f.fsf@thinkpad.tsdh.de> <85txygk74a.fsf@iznogoud.viz> <87y5nsbqj4.fsf@thinkpad.tsdh.de> <85pq94k37p.fsf@iznogoud.viz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1339518771 19810 80.91.229.3 (12 Jun 2012 16:32:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Jun 2012 16:32:51 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M30196@lists.math.uh.edu Tue Jun 12 18:32:49 2012 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SeU1L-0004g2-Pf for ding-account@gmane.org; Tue, 12 Jun 2012 18:32:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1SeU0U-0002Xk-AF; Tue, 12 Jun 2012 11:31:50 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SeU0R-0002XX-Lk for ding@lists.math.uh.edu; Tue, 12 Jun 2012 11:31:47 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SeU0D-0003L3-I2 for ding@lists.math.uh.edu; Tue, 12 Jun 2012 11:31:47 -0500 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1SeU0B-0005XI-Vu for ding@gnus.org; Tue, 12 Jun 2012 18:31:32 +0200 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 3A1DBD26DC for ; Tue, 12 Jun 2012 18:31:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBnR5hhcAo6e for ; Tue, 12 Jun 2012 18:31:30 +0200 (CEST) X-CHKRCPT: Envelopesender noch tassilo@member.fsf.org Original-Received: from thinkpad.tsdh.de (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 9F10FD26D8 for ; Tue, 12 Jun 2012 18:31:30 +0200 (CEST) In-Reply-To: <85pq94k37p.fsf@iznogoud.viz> (Wolfgang Jenkner's message of "Tue, 12 Jun 2012 16:35:38 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.0.97 (gnu/linux) X-Spam-Score: -4.9 (----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:81926 Archived-At: Wolfgang Jenkner writes: >> It matches the behavior in that it had to fetch 2 additional messages >> to fill in gaps in lose thread branches. > > The docstring states that it fetches all old headers (though only some > subset of them is displayed). You are right. But speaking from experience it didn't do so, yet the effect of connecting loose threads with old read articles somehow seemed to work. Ok, now I've edebugged the function as you suggested and checked what's going on. The difference between now and then is that now all headers of a group are fetched once and put into the .overview (NOV) files. Then they are cached and entering a group (even with 'some) is fast again. So basically, before uncached-articles was always the list of unread articles, now it is (set-difference all-articles articles-in-overview). (if (setq uncached-articles (gnus-agent-uncached-articles articles group t)) (progn ;; Populate nntp-server-buffer with uncached headers (set-buffer nntp-server-buffer) (erase-buffer) The reason that I get those excessive nntp reads (only once for each group) is that my overview files didn't start with article 1, because when subscribing to a new group, I restricted fetching by entering it with, say, C-u 1000 RET and then catching up. So to conclude: - Your patch is correct with respect to the docs - Your patch is bad, because now you can't use 'some for `gnus-fetch-old-headers' unless you have a super-fast internet connection. (Several gmane groups have millions of messages which on first entering will all be downloaded. No way to restrict that with a prefix arg as I always did. Also, you end up with huge .overview files, which slow down Gnus' operations quite a bit.) - The old and buggy 'some semantics of `gnus-fetch-old-headers' were exactly what I want. I.e., I want Gnus to *fetch* only new messages, but it should also *display* summary lines of old messages to fill loose threads in case those can be determined from the overview. Now what? Possibly `gnus-fetch-old-headers' should be split into two variables to entangle fetching from displaying? That'd be pretty bad with respect to backwards compatibility... Or how about allowing values like '(some . 100) meaning fetch at most 100 old headers and display old articles where needed to fill loose threads? Bye, Tassilo