From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/3625 Path: news.gmane.org!not-for-mail From: Nuutti Kotivuori Newsgroups: gmane.emacs.gnus.user Subject: Re: nnimap slow on big groups Date: Mon, 15 Mar 2004 21:27:46 +0200 Organization: Ye 'Ol Disorganized NNTPCache groupie Message-ID: <87ish5uczx.fsf@aka.i.naked.iki.fi> References: <87n06r9epg.fsf@aka.i.naked.iki.fi> <87brmyv3rh.fsf@aka.i.naked.iki.fi> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138669675 19629 80.91.229.2 (31 Jan 2006 01:07:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2006 01:07:55 +0000 (UTC) Original-X-From: nobody Tue Jan 17 17:32:30 2006 Original-Path: quimby.gnus.org!newsfeed1.e.nsc.no!nsc.no!nextra.com!uio.no!news.tele.dk!news.tele.dk!small.news.tele.dk!news-stoc.telia.net!news-stoa.telia.net!telia.net!nntp.inet.fi!inet.fi!feeder1.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.gnus User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) Cancel-Lock: sha1:2Pj3wVrz82X5e+kCPyH3/APZ7ms= Cache-Post-Path: aka.i.naked.iki.fi!unknown@aka.i.naked.iki.fi X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Original-NNTP-Posting-Host: 62.142.249.112 Original-X-Complaints-To: newsmaster@saunalahti.com Original-X-Trace: reader1.news.jippii.net 1079378867 62.142.249.112 (Mon, 15 Mar 2004 21:27:47 EET) Original-NNTP-Posting-Date: Mon, 15 Mar 2004 21:27:47 EET Original-Xref: bridgekeeper.physik.uni-ulm.de gnus-emacs-gnus:3766 Original-Lines: 36 X-Gnus-Article-Number: 3766 Tue Jan 17 17:32:30 2006 Xref: news.gmane.org gmane.emacs.gnus.user:3625 Archived-At: Simon Josefsson wrote: > Nuutti Kotivuori writes: >> The problem is that nnimap checks if the read article ranges >> correspond to the 'seen' list on the server, and so fetches only >> the article numbers of 65k seen articles - but even that is >> excessive. > > I think that is by design, and there isn't, AFAIK, any simple way of > fixing it. Changing the design is one option, but that is typically > non-trivial. Okay, this doesn't completely alleviate the problem, but: ,----[ nnimap-request-update-info-internal ] | ;; seen might lack articles marked as read by other | ;; imap clients! we correct this | seen (append seen (imap-search "SEEN")) `---- What will happen if this is not done? Will it mean that those articles will appear unread in Gnus until read in Gnus - or will it just mean that those articles show up in the summary buffer but when their flags are fetched, they will be shown as seen anyway? Or will there be spontaneous internal combustion later on? That place is the only place that bothers me in daily use - and I can live with either option 1 or 2 - and I might try fixing option 3 if it so happens. Or if none of those work too well, I might change the seen to search only the latest week by arrival times, which would be quite okay by me. Ofcourse this does not remove the fact that the whole read range is first uncompressed, then differenced and then compressed again, which again on a 65k article list is not neglible, but it is not too bad. -- Naked