nnfolder change?

nnfolder change?

[Stephen Berman]

I use nnfolder as my mail backend.  Sometime since September 9, there
was a change with the effect that, when I start Gnus, all my mail
directories in ~/Mail are visited and their buffers are added to the
buffer list; this does not happen in my September 9 build.  Moreover,
the startup time is noticeably slowly that with the September 9 build.
At least the latter I would regard as a regression, but it's also
annoying to have the buffer list pollution.  Are these effects bugs or
intentional, and if the latter, are there any variables I can set to
change back to the previous behavior?

Steve Berman

Re: nnfolder change?

[Dan Christensen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I use nnfolder as my mail backend.  Sometime since September 9, there
> was a change with the effect that, when I start Gnus, all my mail
> directories in ~/Mail are visited and their buffers are added to the
> buffer list; this does not happen in my September 9 build.  

I can confirm that this happens with git gnus, at least for nnfolder
groups whose levels are low enough.

> Moreover, the startup time is noticeably slowly that with the
> September 9 build.

I've had mixed results measuring this.  Sometimes the recent gnus
is a lot slower than my old Dec 2009 install, but most of the time
it is faster.  But I don't have very many nnfolder groups at a low
level.

You can use benchmark.el to get precise timing results:

  M-x load-library RET benchmark RET
  M-x benchmark RET (gnus) RET

Dan

Re: nnfolder change?

[Stephen Berman]

On Mon, 20 Sep 2010 11:08:34 -0400 Dan Christensen <jdc@uwo.ca> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I use nnfolder as my mail backend.  Sometime since September 9, there
>> was a change with the effect that, when I start Gnus, all my mail
>> directories in ~/Mail are visited and their buffers are added to the

s/directories/files/

>> buffer list; this does not happen in my September 9 build.  

                                                     8
>
> I can confirm that this happens with git gnus, at least for nnfolder
> groups whose levels are low enough.
>

Good to know it's not an idiosyncrasy of my setup.

>> Moreover, the startup time is noticeably slowly that with the

                                            slower than

>> September 9 build.
>
> I've had mixed results measuring this.  Sometimes the recent gnus
> is a lot slower than my old Dec 2009 install, but most of the time
> it is faster.  But I don't have very many nnfolder groups at a low
> level.
>
> You can use benchmark.el to get precise timing results:
>
>   M-x load-library RET benchmark RET
>   M-x benchmark RET (gnus) RET

Thanks for the pointer; here are my measurements:

2010-09-08 build: Elapsed time: 3.953596s (1.693183s in 24 GCs)
2010-09-17 build: Elapsed time: 9.543028s (2.021980s in 27 GCs)

Steve Berman

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I use nnfolder as my mail backend.  Sometime since September 9, there
> was a change with the effect that, when I start Gnus, all my mail
> directories in ~/Mail are visited and their buffers are added to the
> buffer list; this does not happen in my September 9 build. 

What's your setup like?  Could you post the `G E' output from a few of
the nnfolder groups that are activated?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Tue, 21 Sep 2010 18:13:56 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I use nnfolder as my mail backend.  Sometime since September 9, there
>> was a change with the effect that, when I start Gnus, all my mail
>> directories in ~/Mail are visited and their buffers are added to the
>> buffer list; this does not happen in my September 9 build. 
>
> What's your setup like?  

Pretty basic, I think:

(setq gnus-select-method '(nntp "news.gmane.org"))
(setq gnus-secondary-select-methods 
      '((nnfolder "private")))

Plus a number of hooks for displaying, sorting, highlighting, etc.

FWIW, my ~/Mail/active file contains 69 group entries.

>                          Could you post the `G E' output from a few of
> the nnfolder groups that are activated?

Appended below.

Steve Berman


[-- Attachment #2: G E output 1 --]
[-- Type: text/plain, Size: 2119 bytes --]

;;; Editing the group info for `nnfolder+private:comp.misc'.
;; Type `C-c C-c' after you've finished editing.

("nnfolder+private:comp.misc" 1
 ((1 . 1354)
  (1356 . 1428)
  (1430 . 1432)
  (1434 . 1460)
  (1462 . 1465))
 ((seen
   (1 . 436)
   438
   (442 . 549)
   (551 . 1180)
   (1183 . 1465))
  (forward 198)
  (reply
   (177 . 178)
   185 188 325 457 460 464
   (479 . 480)
   564 575 684
   (723 . 724)
   869 872
   (965 . 966)
   1380)
  (tick
   (5 . 7)
   37
   (43 . 48)
   (51 . 52)
   54
   (62 . 64)
   (75 . 77)
   (80 . 86)
   97 101 104 112 115
   (142 . 156)
   159
   (163 . 165)
   (172 . 173)
   175
   (177 . 186)
   (188 . 191)
   (193 . 195)
   (198 . 199)
   201
   (205 . 208)
   (216 . 219)
   (238 . 243)
   (248 . 249)
   (253 . 254)
   265
   (270 . 271)
   279 281
   (283 . 285)
   (287 . 288)
   (290 . 293)
   301 316 318
   (325 . 326)
   334 338 340 343
   (365 . 366)
   (381 . 386)
   (404 . 407)
   428 430
   (457 . 458)
   (460 . 466)
   (474 . 476)
   (478 . 484)
   494 502
   (511 . 513)
   528 544 561 564 566 568
   (575 . 576)
   597
   (602 . 604)
   (607 . 609)
   612 616
   (660 . 661)
   665
   (669 . 670)
   679
   (684 . 686)
   688
   (698 . 701)
   712
   (714 . 720)
   (723 . 726)
   (728 . 731)
   741
   (747 . 749)
   (751 . 752)
   (757 . 758)
   761 783 826 835 837 846 850 852 859 863
   (869 . 873)
   (875 . 876)
   885
   (890 . 892)
   (894 . 895)
   898
   (908 . 910)
   930 941
   (947 . 948)
   954 956 960
   (962 . 963)
   (965 . 972)
   (993 . 994)
   998 1001 1006
   (1009 . 1010)
   1012 1015 1023 1025
   (1028 . 1031)
   1041
   (1043 . 1044)
   1050
   (1053 . 1054)
   (1067 . 1069)
   1074 1085 1096
   (1098 . 1099)
   1105 1120 1133 1136 1139 1141 1144
   (1147 . 1148)
   1150
   (1160 . 1161)
   1166 1168
   (1171 . 1172)
   1186 1202
   (1209 . 1210)
   1239
   (1243 . 1245)
   1248 1256 1259 1268 1272 1276 1280 1296 1299 1303 1307
   (1315 . 1316)
   1331 1371
   (1380 . 1382)
   1400 1425
   (1427 . 1428)
   1432
   (1434 . 1435)
   (1440 . 1446)
   (1448 . 1454)
   (1459 . 1460)
   (1462 . 1465)))
 "nnfolder:private")


[-- Attachment #3: G E output 2 --]
[-- Type: text/plain, Size: 296 bytes --]

;;; Editing the group info for `nnfolder+private:suse.security.announce'.
;; Type `C-c C-c' after you've finished editing.

("nnfolder+private:suse.security.announce" 1
 ((1 . 772))
 ((seen
   (188 . 772))
  (tick 377 404 466 470 523 576 588 619 701 732
	(752 . 753)
	761))
 "nnfolder:private")


[-- Attachment #4: G E output 3 --]
[-- Type: text/plain, Size: 753 bytes --]

;;; Editing the group info for `nnfolder+private:emacs.personal'.
;; Type `C-c C-c' after you've finished editing.

("nnfolder+private:emacs.personal" 1
 ((1 . 5121))
 ((seen
   (1 . 43)
   (4135 . 5121))
  (forward 4137)
  (save
   (4137 . 4139))
  (reply 18 23 28
	 (32 . 33)
	 (35 . 36)
	 42 4137
	 (4146 . 4148)
	 4179
	 (4193 . 4195)
	 (4199 . 4201)
	 (4217 . 4218)
	 (4220 . 4221)
	 4237 4245 4247 4284 4372
	 (4424 . 4425)
	 4446 4549 4551 4553 4557 4578 4643 4647 4662 4668 4766 4775 4819 4824 4898 4925 4954 4958
	 (4969 . 4970)
	 (5032 . 5033)
	 5051
	 (5053 . 5055)
	 5081 5106)
  (tick
   (1 . 43)
   (4137 . 4881)
   (4883 . 4886)
   (4888 . 4951)
   (4953 . 4955)
   (4957 . 5033)
   (5035 . 5057)
   (5067 . 5121)))
 "nnfolder:private")


[-- Attachment #5: G E output 4 --]
[-- Type: text/plain, Size: 1360 bytes --]

;;; Editing the group info for `nnfolder+private:bug.gnu.emacs'.
;; Type `C-c C-c' after you've finished editing.

("nnfolder+private:bug.gnu.emacs" 3
 ((1 . 6110))
 ((reply 14
	 (1237 . 1238)
	 1254 1432 2049 5106 5222 5610)
  (tick 1 14
	(52 . 53)
	(190 . 191)
	778 1187
	(1237 . 1238)
	1254 1402 1429
	(1432 . 1433)
	1436 1504 1726 2049 3070 4074 4391 4452 4492 5084 5095 5106 5116 5154 5222
	(5246 . 5247)
	5253 5278 5389 5610 5708 5790 5846 5950 6083 6094 6096 6110)
  (seen 1 14 47
	(51 . 53)
	58 60 62 73 75 89 143 153 159
	(190 . 191)
	194 198 294 311 367 730 762 778 1064 1089 1120 1122 1153 1161 1175 1178 1183 1187 1214
	(1237 . 1238)
	1251 1254 1338 1402 1429
	(1432 . 1433)
	1436 1504 1578 1589 1600 1618 1622 1666 1719 1726 1823 1828 1837 2049 2388 2689 2755 2763 3020 3044 3050 3070 3102 3115 3164 3283 3348 3381
	(3388 . 3389)
	3565
	(3568 . 3569)
	3825 3859 3868 3898 3901 3903 3913 3927 3980 4035 4074 4118 4152 4155 4205 4232 4243 4246 4304 4328 4334 4391 4437 4452 4492 4546 4584 4624 4670 4678 4684
	(4704 . 4705)
	4733 4741 4753 4767 4769 4771 4785 4847 4968 4977 4984 4991 4993 4997
	(5014 . 5015)
	5072
	(5081 . 5082)
	5084 5095 5106 5116 5154 5206 5222
	(5246 . 5247)
	5253 5278 5345 5366 5389 5422 5431 5534 5585 5597 5610 5652 5708 5736 5790 5837 5846
	(5860 . 6146)))
 "nnfolder:private"
 ((to-address . "bug-gnu-emacs@gnu.org")))

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> (setq gnus-select-method '(nntp "news.gmane.org"))
> (setq gnus-secondary-select-methods 
>       '((nnfolder "private")))

[...]

>  "nnfolder:private")

Looks very normal.  Hm...  Well, this may have been related to the
server method equivalence code, which may mean that it's been fixed by
the stuff I just checked in.  But I'm not sure at all...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Stephen Berman]

On Tue, 21 Sep 2010 23:11:36 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> (setq gnus-select-method '(nntp "news.gmane.org"))
>> (setq gnus-secondary-select-methods 
>>       '((nnfolder "private")))
>
> [...]
>
>>  "nnfolder:private")
>
> Looks very normal.  Hm...  Well, this may have been related to the
> server method equivalence code, which may mean that it's been fixed by
> the stuff I just checked in.  But I'm not sure at all...

I just updated from the trunk, which I believe includes your changes,
and bootstrapped, and unfortunately all the mail files under ~/Mail
still get loaded into buffers on starting Gnus, and the startup time was
now about 30% slower than with my previous build :-(

Elapsed time: 13.734284s (2.105971s in 27 GCs)

Steve Berman

Re: nnfolder change?

[Dan Christensen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I just updated from the trunk, which I believe includes your changes,
> and bootstrapped, and unfortunately all the mail files under ~/Mail
> still get loaded into buffers on starting Gnus

I also still get lots of nnfolder groups creating buffers that stick
around.  And I also get a lot of nnimap buffers for a remote imap
server that I don't actually use much:

  * *nnimap jdc.math.uwo.: 161  Fundamental
  * *nnimap jdc.math.u:<2> 256  Fundamental
  * *nnimap jdc.math.u:<3> 256  Fundamental
  * *nnimap jdc.math.u:<4> 256  Fundamental
  * *nnimap jdc.math.u:<5> 256  Fundamental
  * *nnimap jdc.math.u:<6> 256  Fundamental
  * *nnimap jdc.math.u:<7> 256  Fundamental
  * *nnimap jdc.math.u:<8> 256  Fundamental
  * *nnimap jdc.math.u:<9> 256  Fundamental
  * *nnimap jdc.math.:<10> 256  Fundamental
  * *nnimap jdc.math.:<11> 190  Fundamental

My local imap server only has one buffer.

Dan

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I just updated from the trunk, which I believe includes your changes,
> and bootstrapped, and unfortunately all the mail files under ~/Mail
> still get loaded into buffers on starting Gnus, and the startup time was
> now about 30% slower than with my previous build :-(

Geez.

What does the following say?

(gnus-find-method-for-group "nnfolder+private:comp.misc")

And try it on a couple of different nnfolder groups.  If they all return
exactly the same thing, then I'm looking at the wrong place to try to
debug this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I also still get lots of nnfolder groups creating buffers that stick
> around.  And I also get a lot of nnimap buffers for a remote imap
> server that I don't actually use much:
>
>   * *nnimap jdc.math.uwo.: 161  Fundamental
>   * *nnimap jdc.math.u:<2> 256  Fundamental
>   * *nnimap jdc.math.u:<3> 256  Fundamental
>   * *nnimap jdc.math.u:<4> 256  Fundamental
>   * *nnimap jdc.math.u:<5> 256  Fundamental

This again points to the thing I thought was wrong.

Could you, too, do a

(gnus-find-method-for-group "nnimap+that.server:a.few.groups")

on a few group names and post the output?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> I also still get lots of nnfolder groups creating buffers that stick
>> around.  And I also get a lot of nnimap buffers for a remote imap
>> server that I don't actually use much:
>>
>>   * *nnimap jdc.math.uwo.: 161  Fundamental
>>   * *nnimap jdc.math.u:<2> 256  Fundamental
>>   * *nnimap jdc.math.u:<3> 256  Fundamental
>>   * *nnimap jdc.math.u:<4> 256  Fundamental
>>   * *nnimap jdc.math.u:<5> 256  Fundamental
>
> This again points to the thing I thought was wrong.
>
> Could you, too, do a
>
> (gnus-find-method-for-group "nnimap+that.server:a.few.groups")
>
> on a few group names and post the output?

I tried on about 8 of the 12 groups, and every one had the following:

  (nnimap "jdc" (nnimap-address "jdc.math.uwo.ca") (nnimap-stream shell))

Some more information:  all of the groups on that server are at level 5,
so they are not activated by default.  And most of the buffers contain
just the following:

-----
* CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1.
3290 OK Capability completed..
Read from remote host jdc.math.uwo.ca: Connection reset by peer.

Process *nnimap*<1> exited abnormally with code 255
-----

Some of them contain:

-----
* SEARCH 6271 6272 6273 6274 6276 6277 6278 6279 6285.
3447 OK Search completed (0.000 secs)..
* BYE Disconnected for inactivity..

Process *nnimap*<1> finished
-----

So maybe this has something to do with having a server with no groups
below the current active level?  The same is true for many of my
nnfolder groups.

Dan

Re: nnfolder change?

[Stephen Berman]

On Wed, 22 Sep 2010 18:29:02 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I just updated from the trunk, which I believe includes your changes,
>> and bootstrapped, and unfortunately all the mail files under ~/Mail
>> still get loaded into buffers on starting Gnus, and the startup time was
>> now about 30% slower than with my previous build :-(
>
> Geez.
>
> What does the following say?
>
> (gnus-find-method-for-group "nnfolder+private:comp.misc")

(nnfolder "private")

> And try it on a couple of different nnfolder groups.  If they all return
> exactly the same thing, then I'm looking at the wrong place to try to
> debug this.

Every group in ~/Mail/active returns (nnfolder "private").

Steve Berman

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I tried on about 8 of the 12 groups, and every one had the following:
>
>   (nnimap "jdc" (nnimap-address "jdc.math.uwo.ca") (nnimap-stream shell))
>
> Some more information:  all of the groups on that server are at level 5,
> so they are not activated by default.  And most of the buffers contain
> just the following:
>
> -----
> * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1.
> 3290 OK Capability completed..
> Read from remote host jdc.math.uwo.ca: Connection reset by peer.
>
> Process *nnimap*<1> exited abnormally with code 255
> -----

Hm.

With the change I pushed right now, could you try eval-in the following
in a few of the *nnimap ... * buffers?

(nnimap-server nnimap-object)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

>> (gnus-find-method-for-group "nnfolder+private:comp.misc")
>
> (nnfolder "private")

What's your nnfolder-get-new-mail variable?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> What's your nnfolder-get-new-mail variable?

Mine is t.

Dan

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

>> What's your nnfolder-get-new-mail variable?
>
> Mine is t.

Ok; then I see what's going on with nnfolder.  But I'm not quite sure
what the fix here is...  hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> With the change I pushed right now, could you try eval-in the following
> in a few of the *nnimap ... * buffers?
>
> (nnimap-server nnimap-object)

I just did a git pull and restarted emacs and gnus, and now there are
no *nnimap...* buffers for that jdc server (which is good, because its
groups are at a high level and so shouldn't be activated).  I'll let you
know if they show up again.

But I still do get lots of nnfolder buffers hanging around.

Dan

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ok; then I see what's going on with nnfolder.  But I'm not quite sure
> what the fix here is...  hm...

I *think* I now understand how this is supposed to work, but I'm not
100% sure.  I pushed out a fix, anyway...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I *think* I now understand how this is supposed to work, but I'm not
> 100% sure.  I pushed out a fix, anyway...

Well, it seems to work.  Now I don't see any nnfolder buffers after
starting Gnus, and the same is true after activating a few nnfolder
groups and entering them.

Thanks!

Dan

Re: nnfolder change?

[Stephen Berman]

On Wed, 22 Sep 2010 15:32:48 -0400 Dan Christensen <jdc@uwo.ca> wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> What's your nnfolder-get-new-mail variable?
>
> Mine is t.

Mine is nil (I populate /var/spool/mail/ via fetchmail to prefilter and
transfer mail from there to Gnus manually with `C-u 1 g').
Nevertheless...

On Wed, 22 Sep 2010 16:39:52 -0400 Dan Christensen <jdc@uwo.ca> wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I *think* I now understand how this is supposed to work, but I'm not
>> 100% sure.  I pushed out a fix, anyway...
>
> Well, it seems to work.  Now I don't see any nnfolder buffers after
> starting Gnus, and the same is true after activating a few nnfolder
> groups and entering them.

I applied the patch manually (it hasn't been merged to trunk yet),
rebuilt and am pleased to confirm Dan's observation about nnfolder
groups.  Moreover, the startup time has improved markedly (though it's
still around 20% slower than with my build of September 8):

Elapsed time: 5.035977s (1.681695s in 24 GCs)

> Thanks!
>
> Dan

Ditto!

Steve Berman

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> Moreover, the startup time has improved markedly (though it's
> still around 20% slower than with my build of September 8):
>
> Elapsed time: 5.035977s (1.681695s in 24 GCs)

I'd be interested in knowing what takes time here, but it's a bit
difficult to figure out.  Hm.

I've now added tracing to `gnus-open-server'.  You'll get a new buffer
called *gnus trace* that records all times and what servers we're
opening.  This should at least give a hint as to where the time is being
spent. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnfolder change?

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Thu, 23 Sep 2010 00:33:59 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Moreover, the startup time has improved markedly (though it's
>> still around 20% slower than with my build of September 8):
>>
>> Elapsed time: 5.035977s (1.681695s in 24 GCs)
>
> I'd be interested in knowing what takes time here, but it's a bit
> difficult to figure out.  Hm.

With the latest changes, the startup time was:

Elapsed time: 4.691736s (2.069494s in 24 GCs)

> I've now added tracing to `gnus-open-server'.  You'll get a new buffer
> called *gnus trace* that records all times and what servers we're
> opening.  This should at least give a hint as to where the time is being
> spent. 

Here it is:


[-- Attachment #2: Gnus trace --]
[-- Type: text/plain, Size: 636 bytes --]

10:17:21 (nntp "news.gmane.org")
10:17:23 (nnfolder "private")
10:17:23 (nnfolder "archive" (nnfolder-directory "~/Mail/archive") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t))
10:17:23 (nnfolder "private")
10:17:23 (nnfolder "archive" (nnfolder-directory "~/Mail/archive") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t))
10:17:23 (nnfolder "private")
10:17:23 (nnfolder "archive" (nnfolder-directory "~/Mail/archive") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t))

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


Steve Berman

Re: nnfolder change?

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> Here it is:
> 10:17:21 (nntp "news.gmane.org")
> 10:17:23 (nnfolder "private")

Looks like most time is spent reading the active file from Gmane, I
guess.  This is actually possible to stream -- I could add -early and
-finish methods for nntp, so that Gnus can carry on working instead of
waiting for the data from the nntp server(s).  In some use cases, that
should give a good speed boost, especially if you have many servers, and
one (or more) of them have bad latency.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen