* speed of Gnus @ 2005-04-11 8:44 Peter Petersen 2005-04-11 10:54 ` Alexander Syrov 0 siblings, 1 reply; 3+ messages in thread From: Peter Petersen @ 2005-04-11 8:44 UTC (permalink / raw) Hello, This time I need to voice some frustration, unfortunately. :-( After having customized Gnus more and more to my needs, I now find that working with it is unbearable in some cases: Entering groups with thousands of articles! Recently I tried to open a huge group with more than 40000 posts: Gnus started to work and work around for hours (sic!) without ever letting me see the summary buffer! After 3 or 4 hours I had lost my patience and did a control-g, which immediately interrupted the crazy process. So Gnus was NOT hung! I compared that to other newsreaders: Forte Agent needed 7 minutes! (about 6 minutes to download all the headers, which was about the same time for Gnus, and then only a few seconds to actually allow me to see the list of articles) Ditto for slrn and tin. In the meantime I upgraded Gnus from 5.10.6 to 5.10.7 and the situation has improved considerably, BUT: Now having to wait about 40 minutes until I can enter a group with 40000 articles - while a huge step forward - is still unacceptable! Moreover, CPU load is still close to 100% - blocking other programs and making it impossible to play an online game, for instance (while Gnus is generating the summary, even after downloading the articles is over). When does the huge delay happen? Well, it happens after having downloaded the headers. It's the time until "generating summary" can be read AND (even more so, perhaps) the time until "generating summary... done" can be seen. But what seems to take most of the time actually is: the time between "generating summary... done" and seeing the headers list! I already applied some hints and tips I found while googling: - simplifying the summary line - putting (gnus-compile) at the bottom of .gnus - entering the corresponding groups with escape-enter instead of enter - sorting by article number (instead of date) - .... There seems to be a _slight_ improvement, but all in all not much has changed. Now you may ask why I have to open such huge groups (or rather: downloading thousands of headers)... Well I always do it this way; it doesn't mean that I read all those articles (oh NO!), but I can search through them for keywords like "via ac97", "crypto file system" or whatever. I actually like to get _all_ the available headers in a group when I am actively searching for a solution. Other newsreaders allow me to do this. I now realize again why I had such a hard time (in the past) coming away from Forte Agent: I can open the hugest of the huge groups and rapidly see its headers, mark them as I please, sort them as I please, easily switch between offline and online mode (or use them simultaneously: downloading headers in _one_ group, downloading bodies in other groups - while at the same time selectively opening articles in some groups via visual inspection and just because I am curious...), I can easily watch threads and "lock" articles which thusly are protected against deleting or "compacting" the database (or expiring). All of the other newsreaders available for unix systems don't seem to offer those vital features (slrn, tin etc.), the only exception being Gnus! Or am I wrong here? - Do slrn or tin offer a way to save interesting articles in such a way that they are visible _inside_ the corresponding group? (like Gnus does with its caching or Forte Agent with its "lock symbol"). I don't think so. But this is a vital feature to me. I want to archive posts this way and be able to always see them in the corresponding group and to be able to post a follow-up from inside the group. What's the consequence? Well, I wouldn't like to return to Forte Agent, because: - I need to run it via "emulation" (Wine) (though it works very well, indeed!) - launching urls, pictures and links is more trouble than worth it (because you have to launch Linux programs from inside a windows application) - Gnus has so many nice additional features (limiting the display of articles according to a multitude of criteria; ticking articles... etc.) - Agent doesn't have unlimited threading depth - Agent doesn't give me all the different colours for quoted text On the other hand scoring (and all the complex possibilities with Gnus) is totally unimportant to me. Ideas anyone? - Can slrn (or tin) save articles in the group? If so: I will switch from Gnus to slrn, most likely ;-) - How to speed up Gnus (if at all possible)? - How do you get along with Gnus and with huge groups? sorry for the rant and thanks again Peter ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: speed of Gnus 2005-04-11 8:44 speed of Gnus Peter Petersen @ 2005-04-11 10:54 ` Alexander Syrov 2005-04-12 12:12 ` Peter Petersen 0 siblings, 1 reply; 3+ messages in thread From: Alexander Syrov @ 2005-04-11 10:54 UTC (permalink / raw) Hello, Peter. On Mon, 11 Apr 2005 10:44:56 +0200 Peter Petersen wrote: 2 years or so ago I too switched from Forte Agent to Gnus. At first I had the same problems as you describe. After a while I realized that using a newsreader the "Gnus way" is also quite comfortable. You can't make Gnus generate summary for thousands of articles quickly enough, but possibly you may live without seeing all those articles at once. PP> Well I always do it this way; it doesn't mean that I read all those PP> articles (oh NO!), but I can search through them for keywords like "via PP> ac97", "crypto file system" or whatever. Searching for articles is much more effective with some indexing software. I use namazu and gnus-namazu.el. Another alternative is nnir.el. It takes a few seconds to process a query and build a virtual group containing the matching articles. PP> easily switch between PP> offline and online mode J j (gnus-agent-toggle-plugged) works in summary and group buffers. PP> (or use them simultaneously: downloading headers PP> in _one_ group, downloading bodies in other groups - while at the same PP> time selectively opening articles in some groups via visual inspection PP> and just because I am curious...), Lack of asyncronous operation is an evident drawback of Gnus. Unfortunately, this functionality can't be easily implemented in Emacs. PP> I can easily watch threads and "lock" PP> articles which thusly are protected against deleting or "compacting" the PP> database (or expiring). You can do it with Gnus. When would you like to mark an article? If you read it the first time or if you come back to it while searching. In the former case, Gnus shows you all the recently fetched articles in default setup (and the old articles in the same threads if you set gnus-fetch-old-headers to t). In the latter case you may search for articles with indexing software. It is much more productive than manually watching over thousands of message headers. PP> - Do slrn or tin offer a way to save interesting articles in such a way PP> that they are visible _inside_ the corresponding group? (like Gnus does PP> with its caching or Forte Agent with its "lock symbol"). I don't think PP> so. You probably need a local newsserver. Gnus Agent eliminates the need for it, but it is neccessary with other newsreaders if you want to create an offline storage for articles. You may try e.g. leafnode. PP> On the other hand scoring (and all the complex possibilities with Gnus) PP> is totally unimportant to me. I recommend you to try using scoring. It helps to deal with lots of mail & news much more quickly. PP> - Can slrn (or tin) save articles in the group? PP> If so: I will switch from Gnus to slrn, most likely ;-) If you definitely can't change you habits, it seems to be the best solution. You may use slrn + local leafnode server. But I recommend to try following the "Gnus way" of reading news for a week or two before taking this decision. Maybe you'll like it better. PP> - How to speed up Gnus (if at all possible)? Not to the extent you want. PP> - How do you get along with Gnus and with huge groups? My news archive (Gnus Agent cache) is over 1 Gb large and contains over 230,000 messages. But I rarely have more than 300-500 articles in summary buffer at once. Scoring helps me to sort out new articles I don't want to read and gnus-namazu allows to search for old articles quickly and effectively. -- Regards, Alexander Syrov. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: speed of Gnus 2005-04-11 10:54 ` Alexander Syrov @ 2005-04-12 12:12 ` Peter Petersen 0 siblings, 0 replies; 3+ messages in thread From: Peter Petersen @ 2005-04-12 12:12 UTC (permalink / raw) * Alexander Syrov <asyrov@mail.ru> schrieb: Hello, Alexander. > newsreader the "Gnus way" is also quite comfortable. You can't make Gnus > generate summary for thousands of articles quickly enough, but possibly you > may live without seeing all those articles at once. In most cases, there is no problem, because the group is not that big. Up to 10000 or with a little bit more patience 15000 the speed of Gnus is still tolerable for me, and fortunately, this is sufficient for most groups, yes. With larger groups I now try to avoid the incredible delay by successively downloading _portions_ of 10000 articles. Of course, this is suboptimal when deciding upon threads to tick or cache. But at least, it is something like a work-around. > PP> Well I always do it this way; it doesn't mean that I read all those > PP> articles (oh NO!), but I can search through them for keywords like "via > PP> ac97", "crypto file system" or whatever. > > Searching for articles is much more effective with some indexing > software. I use namazu and gnus-namazu.el. Another alternative is > nnir.el. It takes a few seconds to process a query and build a virtual > group containing the matching articles. I would have to try this, though I always liked to see _all_ headers (= subjects, topics) and just browse them (with Forte Agent). They may not reflect the most reliable way to find interesting articles, but I still think, visual inspection is unbeaten when compared to any fixed rule or rule set. And searching through article _bodies_ of an entire group or lots of groups was not that slow either with Forte Agent, and it was comfortable. Oh yeah... > PP> easily switch between > PP> offline and online mode > > J j (gnus-agent-toggle-plugged) works in summary and group buffers. I know, but that was not what I was going to say. > PP> (or use them simultaneously: downloading headers > PP> in _one_ group, downloading bodies in other groups - while at the same > PP> time selectively opening articles in some groups via visual inspection > PP> and just because I am curious...), > > Lack of asyncronous operation is an evident drawback of > Gnus. Unfortunately, this functionality can't be easily implemented in Emacs. Now that is what I was referring to... Looks like one has to live with this limitation. > PP> I can easily watch threads and "lock" > PP> articles which thusly are protected against deleting or "compacting" the > PP> database (or expiring). > > You can do it with Gnus. When would you like to mark an article? If you read > it the first time or if you come back to it while searching. In the former > case, Gnus shows you all the recently fetched articles in default setup > (and the old articles in the same threads if you set gnus-fetch-old-headers > to t). In the latter case you may search for articles with indexing > software. It is much more productive than manually watching over thousands > of message headers. I still trust my eyes and my "intuition" or curiosity way more than any fixed rule set. But you are right, other methods _can_ be more productive, especially if they are considerably less time consuming and life doesn't leave you much leasure time any longer. :-( > PP> - Do slrn or tin offer a way to save interesting articles in such a way > PP> that they are visible _inside_ the corresponding group? (like Gnus does > PP> with its caching or Forte Agent with its "lock symbol"). I don't think > PP> so. > > You probably need a local newsserver. Gnus Agent eliminates the need for > it, but it is neccessary with other newsreaders if you want to create an > offline storage for articles. You may try e.g. leafnode. Hehe. :) No, I am through with this chapter, local newsservers. I had tried them years ago (leafnode, inn - and also things like slrnpull or noffle). It proved to be totally impractical for a single user like me (of course, it would be different if I shared my news depot with several or lots of other people: then a newsserver is vital). When I didn't have an adsl connection yet and had to pay per minute for my modem connection, there was nothing, really nothing (none of the often suggested and furiously proclaimed Linux/Unix methods, like running your own news server) that came close to the speed and comfort of running Forte Agent - and yes, I did extended tests and gave local news servers a chance for many months. Agent always turned out to be superior - measured by my own needs and interest, naturally! It is just so much easier to have the flexibility to download all the headers in _one_ specific group, to only download 1000 headers in a couple of other groups, to download all the bodies in yet another group, to download all the marked bodies and watched threads in all the groups, while at the same time spending one's waiting time online picking this or that maybe interesting article and also posting some questions or replies at the same time. Those were the Forte Agent times. ;-) No newsserver solution ever offers that degree of flexibility. Not for a single user who likes to be subscribed to a large number of (partially) large groups and who also likes to easily subscribe or unsubscribe some groups or just have a look in a few other groups, depending on my current interests or open questions... But hey, with my modem times being over, basically (except when ADSL is down), these are all things of the past. Furthermore, there is this _one_ news reader (Gnus) with its Agent mode, something no other reader like slrn, tin etc. offers. > PP> - Can slrn (or tin) save articles in the group? > PP> If so: I will switch from Gnus to slrn, most likely ;-) > > If you definitely can't change you habits, it seems to be the best > solution. You may use slrn + local leafnode server. But I recommend to try > following the "Gnus way" of reading news for a week or two before taking > this decision. Maybe you'll like it better. Except for large groups, I actually like the "Gnus way". > PP> - How to speed up Gnus (if at all possible)? > > Not to the extent you want. O.k., that's what I expected. > PP> - How do you get along with Gnus and with huge groups? > > My news archive (Gnus Agent cache) is over 1 Gb large and contains over > 230,000 messages. But I rarely have more than 300-500 articles in summary > buffer at once. Scoring helps me to sort out new articles I don't want to > read and gnus-namazu allows to search for old articles quickly and > effectively. Many thanks. Regards Peter ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-04-12 12:12 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-04-11 8:44 speed of Gnus Peter Petersen 2005-04-11 10:54 ` Alexander Syrov 2005-04-12 12:12 ` Peter Petersen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).