Re: Improving Gnus speed

[Francis Moreau <francis.moro@gmail.com>]

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

> Francis Moreau <francis.moro@gmail.com> writes:
>
>> Even if articles are cached, Gnus takes some times to display the
>> summary buffer:
>>
>> Entering in the group containing cached articles: 4 secs.
>>
>> This group contains 230 unread articles.
>
> That's obscenely slow.  Even if the 230 articles were fetched over the
> net, it shouldn't take anywhere that long.

That's reassuring.

>> Now display all articles in this group by doing '/ o':
>>
>> Gnus asks me:
>>
>>      How many articles from nnml+cache:nntp+news.free.fr:comp.lang.c (default 42555):
>>
>> Type <RET>.
>>
>>      Fetching headers for nnml+cache:nntp+news.free.fr:comp.lang.c...
>>      < 7 secs>
>>      done
>>      < 22 secs>
>>      Generating summary...
>>      < 3 secs>
>>      done
>
> That seems rather slow, too, but Gnus is rather slow when rendering

I forgot to mention that the number 42555 is wrong, there're actually
only 1298 articles in this buffer.

I don't know why it's wrong though.

> large summary buffers, and I've never understood why, really.  Entering
> a 10K group takes a couple of seconds, but entering a 100K group takes
> several minutes.  So there's something exponential going on somewhere...

That's my impression too.

>> I'm interested in improving this, so any suggestions are welcome.
>
> (setq debug-on-quit t) and then `C-g'-ing a few times should tell you
> what function is taking so long.  `M-x elp-instrument-package RET gnus
> RET', doing something, and then `M-x elp-results' should give you a
> detailed look.

ok, I'll try that and see I can find something.

>> BTW, Gnus is using Git as SCM (cool) but it seems that it uses HTTP
>> method only (not git protocol). Is that right ?
>>
>> IIRC, git protocol is more effective, and I actually don't compile Git
>> with HTTP support since it adds some dependency like curl for no good
>> reason.
>
> The Gnus sources are so small that just using HTTP seems OK to me,
> speedwise.

Well even in that case, why not using the native protocol which is more
efficient, stable ... ?

-- 
Francis