* Gnus vs Wanderlust @ 2004-05-31 10:22 Miguel 2004-05-31 23:03 ` Katsumi Yamaoka 2004-06-01 15:58 ` colin.rafferty 0 siblings, 2 replies; 26+ messages in thread From: Miguel @ 2004-05-31 10:22 UTC (permalink / raw) Hi, I been using Gnus for email only since a while. I think it is a very nice client but I would like to compare it with other Gnu/Emacs email clients. After a quick search, I found no comments comparing Gnus and Wanderlust. Could anyone that has already tried both say something about this topic? Thanks. -- Miguel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-05-31 10:22 Gnus vs Wanderlust Miguel @ 2004-05-31 23:03 ` Katsumi Yamaoka 2004-06-01 12:41 ` Lloyd Zusman 2004-06-01 15:58 ` colin.rafferty 1 sibling, 1 reply; 26+ messages in thread From: Katsumi Yamaoka @ 2004-05-31 23:03 UTC (permalink / raw) Cc: wl-en >>>>> In <loom.20040531T121715-288@post.gmane.org> >>>>> Miguel <umiguel@alunos.deis.isec.pt> wrote: > Hi, > I been using Gnus for email only since a while. I think it is > a very nice client but I would like to compare it with other > Gnu/Emacs email clients. After a quick search, I found no > comments comparing Gnus and Wanderlust. Could anyone that has > already tried both say something about this topic? > Thanks. Well, I cannot say in a word but Wanderlust is also a good mail and newsreader. It supports many kinds of back ends, GUI, spam filtering, etc. The well-arranged manual is provided and to customize it is easy. Wanderlust is mainly developed by Japanese people, and you can meet them and a lot of users in the following open lists: wl@lists.airs.net (mainly for discussing in Japanese) wl-en@lists.airs.net (for English but gatewayed to wl) To subscribe to them, send a mail including "# guide" in the body to wl-ctl@lists.airs.net or wl-en-ctl@lists.airs.net. -- Katsumi Yamaoka <yamaoka@jpl.org> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-05-31 23:03 ` Katsumi Yamaoka @ 2004-06-01 12:41 ` Lloyd Zusman 2004-06-01 14:40 ` Katsumi Yamaoka 0 siblings, 1 reply; 26+ messages in thread From: Lloyd Zusman @ 2004-06-01 12:41 UTC (permalink / raw) Katsumi Yamaoka <yamaoka@jpl.org> writes: >>>>>> In <loom.20040531T121715-288@post.gmane.org> >>>>>> Miguel <umiguel@alunos.deis.isec.pt> wrote: > >> Hi, > >> I been using Gnus for email only since a while. I think it is >> a very nice client but I would like to compare it with other >> Gnu/Emacs email clients. After a quick search, I found no >> comments comparing Gnus and Wanderlust. Could anyone that has >> already tried both say something about this topic? > >> Thanks. > > Well, I cannot say in a word but Wanderlust is also a good mail > and newsreader. It supports many kinds of back ends, GUI, spam > filtering, etc. The well-arranged manual is provided and to > customize it is easy. [ ... ] I'm interested in trying Wanderlust, and I just now attempted to get a recent version of it on the main site and the mirrors that are listed there. But the latest version I have found is this one which is just under 11 months old: wl-2.10.1.tar.gz Are there any newer versions of this software? Thanks in advance. -- Lloyd Zusman ljz@asfast.com God bless you. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 12:41 ` Lloyd Zusman @ 2004-06-01 14:40 ` Katsumi Yamaoka 2004-06-01 22:47 ` Lloyd Zusman 0 siblings, 1 reply; 26+ messages in thread From: Katsumi Yamaoka @ 2004-06-01 14:40 UTC (permalink / raw) Hi, >>>>> In <m3d64jtpq6.fsf@asfast.com> >>>>> Lloyd Zusman <ljz@asfast.com> wrote: > Are there any newer versions of this software? The latest version can be downloaded by anonymous cvs as follows: % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login CVS password: [CR] # NULL string % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root checkout wanderlust Or you can also get the snapshot which I'm making mostly every day: ftp://ftp.jpl.org/wl/snapshots/wanderlust-2004********.tar.gz or http://www.jpl.org/ftp/wl/snapshots/wanderlust-2004********.tar.gz -- Katsumi Yamaoka <yamaoka@jpl.org> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 14:40 ` Katsumi Yamaoka @ 2004-06-01 22:47 ` Lloyd Zusman 2004-06-02 12:33 ` David Abrahams 0 siblings, 1 reply; 26+ messages in thread From: Lloyd Zusman @ 2004-06-01 22:47 UTC (permalink / raw) Cc: Katsumi Yamaoka Katsumi Yamaoka <yamaoka@jpl.org> writes: > Hi, > >>>>>> In <m3d64jtpq6.fsf@asfast.com> >>>>>> Lloyd Zusman <ljz@asfast.com> wrote: > >> Are there any newer versions of this software? > > The latest version can be downloaded by anonymous cvs as follows: > > % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login > CVS password: [CR] # NULL string > % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root checkout wanderlust > > Or you can also get the snapshot which I'm making mostly every day: > > ftp://ftp.jpl.org/wl/snapshots/wanderlust-2004********.tar.gz > or > http://www.jpl.org/ftp/wl/snapshots/wanderlust-2004********.tar.gz > -- > Katsumi Yamaoka <yamaoka@jpl.org> Thank you very much. I have now downloaded a very recent version of Wanderlust, and I am about to try it. -- Lloyd Zusman ljz@asfast.com God bless you. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 22:47 ` Lloyd Zusman @ 2004-06-02 12:33 ` David Abrahams 0 siblings, 0 replies; 26+ messages in thread From: David Abrahams @ 2004-06-02 12:33 UTC (permalink / raw) Lloyd Zusman <ljz@asfast.com> writes: > Thank you very much. I have now downloaded a very recent version of > Wanderlust, and I am about to try it. Lloyd, I hope you will write a report of your experience (and cc: me when you do ;->). Thanks, Dave ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-05-31 10:22 Gnus vs Wanderlust Miguel 2004-05-31 23:03 ` Katsumi Yamaoka @ 2004-06-01 15:58 ` colin.rafferty 2004-06-01 22:35 ` Miles Bader 1 sibling, 1 reply; 26+ messages in thread From: colin.rafferty @ 2004-06-01 15:58 UTC (permalink / raw) Cc: ding Miguel wrote: > I been using Gnus for email only since a while. I think it is a very > nice client but I would like to compare it with other Gnu/Emacs > email clients. I used VM as a mail reader for about 7 years. I then used Gnus for about two years. I switched back to VM for three more years. I have been using WL for about two months now. I stopped using Gnus for mail because, to paraphrase Kyle Jones, I prefer a mail reader for mail, and a news reader for news. Note that this is a personal decision. When I enter a mail folder, I expect to see all the messages, rather than just the ones for that are new. I prefer to delete messages myself, rather than have them expire. I prefer to have my messages ordered by date rather than by perceived importance. I realize that I have all those options in Gnus. However, those are all working against how Gnus works. I prefer swimming downstream. I switched to WL because at my company, we use imap, and have for a while. Until two months ago, I would use fetchmail+procmail to download, fold, spindle, and mutilate my mail. I would then use VM to read it. I switched to WL because it works with imap, as opposed to VM, which works in spite of imap. I can now keep my mail on the server, and read the 1% of windows-only messages I care about in Thunderbird. I also use nnimap on an experimental basis. However, it is painfully slow to enter a group. For example, right now, my primary inbox shows 15382 messages total. It's sparse -- there are only 707 actual messages. Every time I enter it, it takes between 25 and 30 seconds to generate the threaded summary. That's a long time. I'm running on a 4-way 2.8GHz 6GB unloaded linux box. This makes it effective unusable, since I want to see all my mail, and not just the new mail. VM and WL optimize summary creation by caching the summary. If I get new mail, either one places it in the proper position, so the time spent is proportional to the amount of new mail, rather than the total amount of mail. I love Gnus as a news reader. I use it actively, and think it is the best news reader ever. However, the needs of a mail reader are different from a news reader. -- Colin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 15:58 ` colin.rafferty @ 2004-06-01 22:35 ` Miles Bader 2004-06-01 23:41 ` Katsumi Yamaoka 2004-06-02 15:26 ` colin.rafferty 0 siblings, 2 replies; 26+ messages in thread From: Miles Bader @ 2004-06-01 22:35 UTC (permalink / raw) colin.rafferty@morganstanley.com writes: > I love Gnus as a news reader. I use it actively, and think it is the > best news reader ever. However, the needs of a mail reader are > different from a news reader. I've always thought this was a very silly argument. I also find that I have slightly different preferences for mail and news, but the amount of _shared_ behavior is _huge_. It seems bizarre to say "Oh just implement a completely new system!" instead of just fixing the problems with Gnus. Not only is the amount of duplicated work enormous, but it's a burden for the _user_ to have to learn and configure two separate systems, especially once they start to explore more advanced features. It's possible that the Gnus framework is so ill-suited to, say, caching that this would be even more work, but it seems unlikely. The main complaints I've seen about Gnus behavior with email are (1) summary generation speed, and (2) lack of rmail-style `categories'. I don't know much about (2), but with regards to (1), at least with backends such as nnml -- which does cache summary information, if not pre-formatted summaries -- the main problem I've had seems to be the same that you mention: it deals poorly with sparse article ranges. Fixing this would go a _long_ way towards making it perfect for me. -Miles -- Freedom's just another word, for nothing left to lose --Janis Joplin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 22:35 ` Miles Bader @ 2004-06-01 23:41 ` Katsumi Yamaoka 2004-06-02 0:13 ` Miles Bader 2004-06-02 15:26 ` colin.rafferty 1 sibling, 1 reply; 26+ messages in thread From: Katsumi Yamaoka @ 2004-06-01 23:41 UTC (permalink / raw) >>>>> In <87zn7mvrcl.fsf@tc-1-100.kawasaki.gol.ne.jp> >>>>> Miles Bader <miles@gnu.org> wrote: > I've always thought this was a very silly argument. I also find that I > have slightly different preferences for mail and news, but the amount of > _shared_ behavior is _huge_. It seems bizarre to say "Oh just implement > a completely new system!" instead of just fixing the problems with Gnus. > Not only is the amount of duplicated work enormous, but it's a burden > for the _user_ to have to learn and configure two separate systems, > especially once they start to explore more advanced features. That's right. Using softwares other than Gnus is a burden to me. However, their work of art sometimes gives me a strong inspiration. Conversely, they also study Gnus eagerly and have taken the good features to Wanderlust. I'm maintaining VM and Wanderlust so that they can always be used in my system. :) -- Katsumi Yamaoka <yamaoka@jpl.org> ;; VM stands for View Mail but WL doesn't stand for vieW maiL. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 23:41 ` Katsumi Yamaoka @ 2004-06-02 0:13 ` Miles Bader 0 siblings, 0 replies; 26+ messages in thread From: Miles Bader @ 2004-06-02 0:13 UTC (permalink / raw) Katsumi Yamaoka <yamaoka@jpl.org> writes: > That's right. Using softwares other than Gnus is a burden to me. > However, their work of art sometimes gives me a strong inspiration. > Conversely, they also study Gnus eagerly and have taken the good > features to Wanderlust. I'm maintaining VM and Wanderlust so that > they can always be used in my system. :) I agree, that there's definitely a place for other mail (and news!) software in emacs, as people's tastes vary, and some just don't like Gnus at all. :-O Especially, some people like something very simple like rmail, and it might be hard to make Gnus be like that (I'm not sure... :-). I just think the `mail and news are _different_' argument is way overused.... -Miles -- Fast, small, soon; pick any 2. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-01 22:35 ` Miles Bader 2004-06-01 23:41 ` Katsumi Yamaoka @ 2004-06-02 15:26 ` colin.rafferty [not found] ` <vgvwu2q2d6m.wl-CC0PidyB7H7SDKTOTjYG+/RivMblJc010E9HWUfgJXw@public.gmane.org> ` (2 more replies) 1 sibling, 3 replies; 26+ messages in thread From: colin.rafferty @ 2004-06-02 15:26 UTC (permalink / raw) Miles Bader wrote: > colin.rafferty@morganstanley.com writes: >> I love Gnus as a news reader. I use it actively, and think it is the >> best news reader ever. However, the needs of a mail reader are >> different from a news reader. > I've always thought this was a very silly argument. I also find that I > have slightly different preferences for mail and news, but the amount of > _shared_ behavior is _huge_. I think that from the implementation side, the shared behavior is huge, but on the user end, for me at least, I approach reading mail and reading news very differently. > It seems bizarre to say "Oh just implement a completely new system!" > instead of just fixing the problems with Gnus. That's the advantage of just being a user. > the main problem I've had seems to be the same that you mention: it > deals poorly with sparse article ranges. Fixing this would go a > _long_ way towards making it perfect for me. Having written, and then reread my own article, I've really thought about why it is that I'm not using Gnus for mail, given that I have a imap server. I realize that I agree with you. The only true problem is Summary generation. Everything else is configurable. So how can we fix this? I have 707 messages in a range of 15382 on my imap server. I don't care that the first time I ever read this takes 45 seconds to load. That's 15 seconds to get the headers from the server, and 30 seconds to generate the summary. What I care about is if I receive one more message, while it has cached the information about the previous 707 messages, so the server download is negligible, it still takes 30 seconds to regenerate a summary that is being trivially changed. There are two basic problems with how Gnus does this: 1. It does not cache summary layout information. When it builds a summary, it has to start from scratch. WL always caches, and VM is optionally able to cache. 2. Its method of reloading a group is to tear down the summary and lay it out again, rather than applying a delta. WL and VM both use deltas, so updates are immediate. Both of these choices make a lot of sense for newsgroups, since in general, what was in the summary before has already been read, and the user won't be interested in it again. However, with regular mail, you want to see everything, so it doesn't make sense. So what we need is options that allow us to fix those two problems: 1. Optionally allow for caching of the summary, so it can quickly be rebuilt. 2. Optionally allow M-g to apply deltas rather than tear-down and build-up. Note that if we implement item 1, then item 2 becomes less necessary. -- Colin ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <vgvwu2q2d6m.wl-CC0PidyB7H7SDKTOTjYG+/RivMblJc010E9HWUfgJXw@public.gmane.org>]
* Re: Gnus vs Wanderlust [not found] ` <vgvwu2q2d6m.wl-CC0PidyB7H7SDKTOTjYG+/RivMblJc010E9HWUfgJXw@public.gmane.org> @ 2004-06-02 17:21 ` Jochen Küpper 0 siblings, 0 replies; 26+ messages in thread From: Jochen Küpper @ 2004-06-02 17:21 UTC (permalink / raw) Jumping in here only to give a somewhat different view. I still agree that improved summary generation would be great. On Wed, 02 Jun 2004 11:26:57 -0400 colin rafferty wrote: colin> Both of these choices make a lot of sense for newsgroups, since in colin> general, what was in the summary before has already been read, and the colin> user won't be interested in it again. However, with regular mail, you colin> want to see everything, so it doesn't make sense. I mainly use Gnus as a MUA and use it for that reason. I would be perfectly happy to read the few newsgroups I look at using anything. I have fairly large mail-groups with archived stuff that I always never need. A typical group for me could contain 500 or 2500 messages, most of which are "old". Then there might be 10, sometimes 50 ticked articles I keep "visible" because they require a reaction at some point or another. In addition there are of course often 1--50 new messages when I enter a group. Overall there are typically 10--50 messages to be shown in the summary... Not so bad. (Especially not so bad for my brain wading through a group. With the full list of messages I would go mad.) Then I wanna check an old email I now I stored. Normally it is obvious what group it is in, so I might go there and simply ask for all articles, then limit it to author or subject or search the messages -- this (i.e. opening with all messages) can be horribly slow, maybe also because often message numbers are sparse; however, it doesn't happen too often. So I can live with some delay here... In the end hiding articles and that for me is "added functionality" most MUAs don't provide. Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-02 15:26 ` colin.rafferty [not found] ` <vgvwu2q2d6m.wl-CC0PidyB7H7SDKTOTjYG+/RivMblJc010E9HWUfgJXw@public.gmane.org> @ 2004-06-03 16:39 ` Kai Grossjohann 2004-06-03 19:28 ` colin.rafferty [not found] ` <vgvwu2o1lwc.wl@paias746.morganstanley.com> 2004-06-03 23:26 ` Miles Bader 2 siblings, 2 replies; 26+ messages in thread From: Kai Grossjohann @ 2004-06-03 16:39 UTC (permalink / raw) colin.rafferty@morganstanley.com writes: > There are two basic problems with how Gnus does this: > > 1. It does not cache summary layout information. When it builds a > summary, it has to start from scratch. WL always caches, and VM is > optionally able to cache. The reason is that new articles might change a lot in the summary buffer. Note that you can display things like thread score, and if a thread gains a message, its score will change... > 2. Its method of reloading a group is to tear down the summary and lay > it out again, rather than applying a delta. WL and VM both use > deltas, so updates are immediate. Perhaps `/ N' does useful things? Kai ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-03 16:39 ` Kai Grossjohann @ 2004-06-03 19:28 ` colin.rafferty [not found] ` <vgvwu2o1lwc.wl@paias746.morganstanley.com> 1 sibling, 0 replies; 26+ messages in thread From: colin.rafferty @ 2004-06-03 19:28 UTC (permalink / raw) Cc: ding Kai Grossjohann wrote: > colin.rafferty@morganstanley.com writes: >> There are two basic problems with how Gnus does this: >> 1. It does not cache summary layout information. When it builds a >> summary, it has to start from scratch. WL always caches, and VM is >> optionally able to cache. > The reason is that new articles might change a lot in the summary > buffer. Note that you can display things like thread score, and if a > thread gains a message, its score will change... I understand completely. While newsgroups and discussion lists are something that I would want to score, and only show the unread articles, I do not want any funky sorting in my primary inbox other than sort by date and use threads. >> 2. Its method of reloading a group is to tear down the summary and lay >> it out again, rather than applying a delta. WL and VM both use >> deltas, so updates are immediate. > Perhaps `/ N' does useful things? It would have been nice. If it really just updated the summary, I would have been able to switch to Gnus. Unfortunately, while it doesn't quit the group and reenter it, it still rebuilds the Summary. -- Colin ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <vgvwu2o1lwc.wl@paias746.morganstanley.com>]
* Re: Gnus vs Wanderlust [not found] ` <vgvwu2o1lwc.wl@paias746.morganstanley.com> @ 2004-06-04 5:16 ` Kai Grossjohann 0 siblings, 0 replies; 26+ messages in thread From: Kai Grossjohann @ 2004-06-04 5:16 UTC (permalink / raw) Cc: Kai Grossjohann, ding colin.rafferty@morganstanley.com writes: > Unfortunately, while [`/ N'] doesn't quit the group and reenter it, > it still rebuilds the Summary. Darn. Kai ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-02 15:26 ` colin.rafferty [not found] ` <vgvwu2q2d6m.wl-CC0PidyB7H7SDKTOTjYG+/RivMblJc010E9HWUfgJXw@public.gmane.org> 2004-06-03 16:39 ` Kai Grossjohann @ 2004-06-03 23:26 ` Miles Bader 2004-06-03 23:39 ` Lloyd Zusman ` (2 more replies) 2 siblings, 3 replies; 26+ messages in thread From: Miles Bader @ 2004-06-03 23:26 UTC (permalink / raw) colin.rafferty@morganstanley.com writes: > 1. It does not cache summary layout information. When it builds a > summary, it has to start from scratch. Is this actually a problem? Judging from what I see, the great bulk of the time is _not_ in summary generation, but rather getting info from the server (which is where the sparse-range problems show up too). [My computer's pretty slow by contemporary standards too -- a 450MHz pentium] I suppose one could try to cache and incrementally update summaries, but summary-generation is already so fast, even for very large groups, that it might make more sense to investigate whether it could be made even faster (maybe even with some new emacs primitives). Having `in between' summary generation might be nice too, especially when just updating a summary buffer with M-g -- for instance, delete and regenerate all threads where anything changed (message disappeared, message added ...) would probably be very fast, as in a large group, this would avoid regenerating most of the summary. -Miles -- Next to fried food, the South has suffered most from oratory. -- Walter Hines Page ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-03 23:26 ` Miles Bader @ 2004-06-03 23:39 ` Lloyd Zusman 2004-06-04 0:05 ` Jesper Harder 2004-06-04 9:41 ` Simon Josefsson 2 siblings, 0 replies; 26+ messages in thread From: Lloyd Zusman @ 2004-06-03 23:39 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > colin.rafferty@morganstanley.com writes: >> 1. It does not cache summary layout information. When it builds a >> summary, it has to start from scratch. > > Is this actually a problem? Judging from what I see, the great bulk of > the time is _not_ in summary generation, but rather getting info from > the server (which is where the sparse-range problems show up too). Well, I found that Wanderlust, which seems to cache and incrementally update summaries, builds the summary buffer for a large (> 10000 messages) IMAP group much faster than Gnus does for the same IMAP group ... at least after the first time I enter the group when all the initial summary building and caching takes place. I understand that Wanderlust doesn't do as much of the fancy stuff that Gnus does, but I am another person who doesn't use those features in my IMAP groups. Perhaps this behavior could become a group-specific option in Gnus ... ??? > [My computer's pretty slow by contemporary standards too -- a 450MHz > pentium] > > I suppose one could try to cache and incrementally update summaries, but > summary-generation is already so fast, even for very large groups, that > it might make more sense to investigate whether it could be made even > faster (maybe even with some new emacs primitives). Well, I have empirical evidence that caching and incrementally updating summaries can indeed make the entry into a large IMAP group considerably faster. > Having `in between' summary generation might be nice too, especially > when just updating a summary buffer with M-g -- for instance, delete and > regenerate all threads where anything changed (message disappeared, > message added ...) would probably be very fast, as in a large group, > this would avoid regenerating most of the summary. Agreed. In fact, this is probably closer to what Wanderlust does. -- Lloyd Zusman ljz@asfast.com God bless you. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-03 23:26 ` Miles Bader 2004-06-03 23:39 ` Lloyd Zusman @ 2004-06-04 0:05 ` Jesper Harder 2004-06-04 0:16 ` Miles Bader 2004-06-04 9:41 ` Simon Josefsson 2 siblings, 1 reply; 26+ messages in thread From: Jesper Harder @ 2004-06-04 0:05 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > colin.rafferty@morganstanley.com writes: >> 1. It does not cache summary layout information. When it builds a >> summary, it has to start from scratch. > > Is this actually a problem? Yes, from my benchmarking it is. > Judging from what I see, the great bulk of the time is _not_ in > summary generation, but rather getting info from the server That may well be the case if you're fetching from an external NNTP server (it also depends on network speed, of course). But if you're fetching from nnml or a local server like Leafnode, summary generation is the major bottleneck. > [My computer's pretty slow by contemporary standards too -- a 450MHz > pentium] I can beat that: 220MHz :-( > I suppose one could try to cache and incrementally update summaries, > but summary-generation is already so fast, even for very large > groups, that it might make more sense to investigate whether it > could be made even faster (maybe even with some new emacs > primitives). Doing some low-level caching would should be quite easy by memoizing. I'm thinking about stuff like `gnus-extract-address-components' which is likely to be called on identical strings many times during summary generation. It probably won't buy us any earth-shattering speedups, but maybe 2-3% here and there. -- Jesper Harder <http://purl.org/harder/> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-04 0:05 ` Jesper Harder @ 2004-06-04 0:16 ` Miles Bader 0 siblings, 0 replies; 26+ messages in thread From: Miles Bader @ 2004-06-04 0:16 UTC (permalink / raw) Jesper Harder <harder@ifa.au.dk> writes: > Doing some low-level caching would should be quite easy by memoizing. > I'm thinking about stuff like `gnus-extract-address-components' which > is likely to be called on identical strings many times during summary > generation. Yeah... Has anyone recently profiled Gnus, and summary generation in particular? I seem to recall (when I only read this mailing list sporadically) Lars at one point going on a major "make Gnus faster" kick, which I think resulted in some noticable gains, but I can't remember when, so maybe that's already factored into the version everybody's using (I'm using Gnus 5.10, and probably won't switch to anything later at least until 5.10 has been integrated into the Emacs tree). -Miles -- Freedom's just another word, for nothing left to lose --Janis Joplin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-03 23:26 ` Miles Bader 2004-06-03 23:39 ` Lloyd Zusman 2004-06-04 0:05 ` Jesper Harder @ 2004-06-04 9:41 ` Simon Josefsson 2004-06-04 16:43 ` Karl Chen 2004-06-05 10:40 ` Miles Bader 2 siblings, 2 replies; 26+ messages in thread From: Simon Josefsson @ 2004-06-04 9:41 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > colin.rafferty@morganstanley.com writes: >> 1. It does not cache summary layout information. When it builds a >> summary, it has to start from scratch. > > Is this actually a problem? Judging from what I see, the great bulk of > the time is _not_ in summary generation, but rather getting info from > the server (which is where the sparse-range problems show up too). Have you disabled the agent cache? Otherwise, headers should be cached, and entering a summary is bounded almost completely by CPU generating the actual summary buffer. For nnimap, Gnus wants to get fresh flags from the server, which can take time if the server is slow, but it doesn't normally download any headers or the like. For nntp, I think the entire delay is in summary buffer generation. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-04 9:41 ` Simon Josefsson @ 2004-06-04 16:43 ` Karl Chen 2004-06-04 19:24 ` Kai Grossjohann 2004-06-05 10:40 ` Miles Bader 1 sibling, 1 reply; 26+ messages in thread From: Karl Chen @ 2004-06-04 16:43 UTC (permalink / raw) When I set gnus-nov-is-evil, summary generation went from 5-10 minutes to very quick. I think it might also have to do with gnus-fetch-old-headers. -- Karl 2004-06-04 09:40 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-04 16:43 ` Karl Chen @ 2004-06-04 19:24 ` Kai Grossjohann 0 siblings, 0 replies; 26+ messages in thread From: Kai Grossjohann @ 2004-06-04 19:24 UTC (permalink / raw) Karl Chen <quarl@nospam.quarl.org> writes: > When I set gnus-nov-is-evil, summary generation went from 5-10 > minutes to very quick. I think it might also have to do with > gnus-fetch-old-headers. Are you saying that gnus-nov-is-evil was nil, and Gnus was slow? And then you set it to t, and Gnus was faster? Very weird. Kai ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-04 9:41 ` Simon Josefsson 2004-06-04 16:43 ` Karl Chen @ 2004-06-05 10:40 ` Miles Bader 2004-06-05 15:14 ` Simon Josefsson 1 sibling, 1 reply; 26+ messages in thread From: Miles Bader @ 2004-06-05 10:40 UTC (permalink / raw) Simon Josefsson <jas@extundo.com> writes: > Have you disabled the agent cache? Otherwise, headers should be > cached, and entering a summary is bounded almost completely by CPU > generating the actual summary buffer. More a case of only recently having switched to Gnus 5.10; this agent stuff is a bit new for me... -Miles -- 自らを空にして、心を開く時、道は開かれる ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-05 10:40 ` Miles Bader @ 2004-06-05 15:14 ` Simon Josefsson 2004-06-06 18:35 ` Karl Chen 0 siblings, 1 reply; 26+ messages in thread From: Simon Josefsson @ 2004-06-05 15:14 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > Simon Josefsson <jas@extundo.com> writes: >> Have you disabled the agent cache? Otherwise, headers should be >> cached, and entering a summary is bounded almost completely by CPU >> generating the actual summary buffer. > > More a case of only recently having switched to Gnus 5.10; this agent > stuff is a bit new for me... It should all be enabled by default. If entering a summary buffer spends more time in the backend than generating the buffer, I think something may be wrong. (Possibly except for the first time you enter the group, if your backend is slow.) Two ELP examples below. First example, entering largish group (~54k articles, C-u RET on gmane.emacs.gnus.general): Function Name Call Count Elapsed Time Average Time ============================================================================ ========== ============ ============ gnus-topic-read-group 1 324.808153 324.808153 gnus-group-read-group 1 324.808111 324.808111 gnus-summary-read-group 1 324.808086 324.808086 gnus-summary-read-group-1 1 324.808077 324.808077 gnus-summary-prepare 1 268.163659 268.163659 gnus-summary-prepare-threads 1 261.31438 261.31438 gnus-select-newsgroup 1 31.384321 31.384321 gnus-fetch-headers 1 30.020259 30.020259 gnus-get-newsgroup-headers-xover 1 29.773468 29.773468 gnus-possibly-score-headers 1 21.369475 21.369475 gnus-score-headers 1 21.368226 21.368226 gnus-score-string 1 20.866281999 20.866281999 gnus-summary-limit-children 53255 20.567338999 0.0003862048 gnus-summary-from-or-to-or-newsgroups 52944 11.471155999 0.0002166658 gnus-run-hooks 52951 10.163973000 0.0001919505 gnus-score-string< 500786 9.0681840000 1.810...e-05 gnus-extract-address-components 52944 8.7819879999 0.0001658731 gnus-sort-threads-1 32267 8.5337919999 0.0002644742 gnus-summary-highlight-line 52943 7.9408890000 0.0001499894 gnus-sort-threads 1 4.780121 4.780121 gnus-put-text-property 105891 3.8764590000 3.660...e-05 gnus-summary-initial-limit 1 3.856649 3.856649 gnus-put-text-property-excluding-characters-with-faces 52944 3.2309779999 6.102...e-05 gnus-make-threads 1 1.616146 1.616146 gnus-thread-sort-by-number 104481 1.5373799999 1.471...e-05 gnus-summary-remove-list-identifiers 1 0.489739 0.489739 gnus-retrieve-headers 2 0.4828179999 0.2414089999 gnus-gather-threads-by-subject 1 0.413676 0.413676 gnus-not-ignore 52922 0.3534540000 6.678...e-06 gnus-articles-to-read 1 0.329798 0.329798 gnus-uncompress-range 1 0.30818 0.30818 gnus-cache-retrieve-headers 1 0.241464 0.241464 gnus-agent-retrieve-headers 1 0.241275 0.241275 gnus-agent-get-undownloaded-list 1 0.095378 0.095378 gnus-thread-loop-p 41419 0.0928350000 2.241...e-06 gnus-summary-highlight-line-0 52943 0.0856470000 1.617...e-06 gnus-compute-unseen-list 1 0.032678 0.032678 gnus-inverse-list-range-intersection 1 0.032666 0.032666 gnus-list-range-difference 1 0.03265 0.03265 gnus-request-group 1 0.029065 0.029065 nntp-request-group 1 0.029011 0.029011 nntp-accept-process-output 30 0.028588 0.0009529333 gnus-agent-uncached-articles 1 0.02776 0.02776 gnus-summary-auto-select-subject 1 0.025996 0.025996 gnus-summary-first-unread-subject 1 0.025987 0.025987 gnus-summary-first-subject 1 0.025938 0.025938 Second example, entering my private inbox for this month, with one unread (spam), where the Group buffer claims 167 messages, but there is only 57 real messages in it (the nnimap-request-group function synchronize flags, and my server is on the other side of a slow network connection -- and still it only amounts to half the slowness): Function Name Call Count Elapsed Time Average Time ============================================================================ ========== ============ ============ gnus-topic-read-group 1 4.250069 4.250069 gnus-group-read-group 1 4.250028 4.250028 gnus-summary-read-group 1 4.249988 4.249988 gnus-summary-read-group-1 1 4.249978 4.249978 gnus-select-newsgroup 1 3.452546 3.452546 gnus-request-group 1 2.716559 2.716559 nnimap-request-group 1 2.716509 2.716509 nnimap-request-update-info-internal 1 2.716264 2.716264 gnus-retrieve-headers 3 2.109038 0.7030126666 gnus-summary-goto-article 1 0.765913 0.765913 gnus-summary-display-article 1 0.7658 0.7658 gnus-fetch-headers 1 0.73178 0.73178 gnus-article-prepare 1 0.721713 0.721713 gnus-cache-retrieve-headers 1 0.718945 0.718945 gnus-agent-retrieve-headers 1 0.718764 0.718764 gnus-request-article-this-buffer 1 0.70749 0.70749 gnus-request-article 1 0.702861 0.702861 nnimap-request-article 1 0.702816 0.702816 nnimap-request-article-part 1 0.702795 0.702795 nnimap-retrieve-headers 1 0.671219 0.671219 nnimap-retrieve-headers-from-server 1 0.67102 0.67102 gnus-run-hooks 72 0.046985 0.0006525694 gnus-agent-fetch-selected-article 1 0.043144 0.043144 gnus-agent-fetch-articles 1 0.042882 0.042882 gnus-agent-save-alist 2 0.0396129999 0.0198064999 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-05 15:14 ` Simon Josefsson @ 2004-06-06 18:35 ` Karl Chen 2004-06-06 20:31 ` Simon Josefsson 0 siblings, 1 reply; 26+ messages in thread From: Karl Chen @ 2004-06-06 18:35 UTC (permalink / raw) Can you profile with a large inbox? For me, small inboxes opened quickly, but my main inbox has 200 MB and 10k messages, taking 10 minutes to open. I think Gnus was doing some kind of iteration through all messages. (I don't use nnimap anymore because of this hassle.) -- Karl 2004-06-06 11:31 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Gnus vs Wanderlust 2004-06-06 18:35 ` Karl Chen @ 2004-06-06 20:31 ` Simon Josefsson 0 siblings, 0 replies; 26+ messages in thread From: Simon Josefsson @ 2004-06-06 20:31 UTC (permalink / raw) Karl Chen <quarl@nospam.quarl.org> writes: > Can you profile with a large inbox? For me, small inboxes opened > quickly, but my main inbox has 200 MB and 10k messages, taking 10 > minutes to open. I think Gnus was doing some kind of iteration > through all messages. (I don't use nnimap anymore because of this > hassle.) Three examples follow. First one is a C-u on INBOX with ~200000 articles according to *Group*, but in reality there is only one read message, taking 9 seconds. Second one C-u on my SpamAssassin folder with ~47500 messages, almost all present, with ~2700 unread, taking 5 minutes. Third one is a normal RET on my SpamAssassin folder, thus showing the ~2700 unread articles, taking 10 seconds. Notice that the time spent in nnimap for the last two cases are about the same, 6 seconds. (I use scoring, but I believe my setup otherwise is pretty standard.) Function Name Call Count Elapsed Time Average Time ============================================================================ ========== ============ ============ gnus-topic-read-group 1 8.569302 8.569302 gnus-group-read-group 1 8.569276 8.569276 gnus-summary-read-group 1 8.569256 8.569256 gnus-summary-read-group-1 1 8.569246 8.569246 gnus-select-newsgroup 1 8.552847 8.552847 gnus-cache-file-contents 6 4.1983489999 0.6997248333 gnus-agent-load-alist 4 4.151504 1.037876 gnus-agent-read-agentview 3 4.150771 1.3835903333 gnus-retrieve-headers 2 3.061173 1.5305865 gnus-request-group 1 2.948282 2.948282 nnimap-request-group 1 2.948238 2.948238 nnimap-request-update-info-internal 1 2.948019 2.948019 gnus-agent-possibly-alter-active 2 2.82466 1.41233 gnus-agent-get-local 2 2.824583 1.4122915 gnus-fetch-headers 1 1.5515780000 1.5515780000 gnus-cache-retrieve-headers 1 1.530634 1.530634 gnus-agent-retrieve-headers 1 1.53045 1.53045 gnus-agent-uncached-articles 1 1.514515 1.514515 gnus-update-read-articles 1 1.334155 1.334155 gnus-get-unread-articles-in-group 1 1.333978 1.333978 gnus-uncompress-range 2 0.779337 0.3896685 gnus-articles-to-read 1 0.466344 0.466344 gnus-sorted-difference 2 0.29461 0.147305 nnimap-possibly-change-group 2 0.258932 0.129466 gnus-set-difference 1 0.214942 0.214942 gnus-make-hashtable 4 0.1764200000 0.0441050000 gnus-agent-get-undownloaded-list 1 0.075068 0.075068 gnus-killed-articles 1 0.067851 0.067851 gnus-agent-load-local 2 0.047461 0.0237305 Function Name Call Count Elapsed Time Average Time ============================================================================ ========== ============ ============ gnus-topic-read-group 1 303.767334 303.767334 gnus-group-read-group 1 303.767305 303.767305 gnus-summary-read-group 1 303.767284 303.767284 gnus-summary-read-group-1 1 303.767274 303.767274 gnus-summary-prepare 1 191.89391 191.89391 gnus-summary-prepare-threads 1 177.632608 177.632608 gnus-select-newsgroup 1 94.833538 94.833538 gnus-fetch-headers 1 87.544199 87.544199 gnus-get-newsgroup-headers-xover 1 87.149547 87.149547 gnus-possibly-score-headers 1 13.255379 13.255379 gnus-score-headers 1 13.254291 13.254291 gnus-score-string 1 12.985546 12.985546 gnus-sort-threads 1 11.593148 11.593148 gnus-sort-threads-1 1 11.590807 11.590807 gnus-run-hooks 47426 9.7569230000 0.0002057294 gnus-summary-highlight-line 47403 8.0100210000 0.0001689770 gnus-summary-from-or-to-or-newsgroups 47403 7.5135199999 0.0001585030 gnus-request-group 1 6.039515 6.039515 nnimap-request-group 1 6.039467 6.039467 nnimap-request-update-info-internal 1 6.039236 6.039236 gnus-thread-sort-by-number 441960 5.6269370000 1.273...e-05 gnus-extract-address-components 47403 5.4056780000 0.0001140366 gnus-score-string< 415224 5.3379850000 1.285...e-05 gnus-put-text-property 94828 3.4712629999 3.660...e-05 gnus-put-text-property-excluding-characters-with-faces 47403 2.8794749999 6.074...e-05 gnus-summary-initial-limit 1 2.360444 2.360444 gnus-gather-threads-by-subject 1 1.506488 1.506488 gnus-summary-goto-article 1 1.39714 1.39714 gnus-summary-display-article 1 1.396983 1.396983 gnus-set-difference 1 0.961172 0.961172 gnus-article-prepare 1 0.890988 0.890988 gnus-sort-gathered-threads 1 0.8835729999 0.8835729999 gnus-request-article-this-buffer 1 0.856863 0.856863 gnus-request-article 2 0.853784 0.426892 nnimap-request-article 2 0.85365 0.426825 nnimap-request-article-part 2 0.8535959999 0.4267979999 gnus-retrieve-headers 2 0.7843359999 0.3921679999 nnimap-possibly-change-group 4 0.5283100000 0.1320775000 gnus-agent-load-alist 4 0.5263519999 0.1315879999 gnus-cache-file-contents 7 0.526071 0.075153 gnus-agent-read-agentview 2 0.525609 0.2628045 gnus-agent-fetch-selected-article 1 0.505478 0.505478 gnus-agent-fetch-articles 1 0.504518 0.504518 gnus-agent-save-alist 1 0.459549 0.459549 gnus-summary-highlight-line-0 47403 0.4439959999 9.366...e-06 gnus-cache-retrieve-headers 1 0.392216 0.392216 gnus-agent-retrieve-headers 1 0.3920280000 0.3920280000 gnus-agent-get-undownloaded-list 1 0.345233 0.345233 gnus-summary-limit-children 47401 0.3448189999 7.274...e-06 gnus-agent-possibly-alter-active 2 0.2930589999 0.1465294999 gnus-agent-get-local 2 0.292991 0.1464955 gnus-make-threads 1 0.271826 0.271826 gnus-agent-uncached-articles 1 0.2620940000 0.2620940000 gnus-summary-remove-list-identifiers 1 0.2241619999 0.2241619999 nnheader-insert-file-contents 4 0.107867 0.02696675 nnheader-insert-nov-file 1 0.107625 0.107625 gnus-uncompress-range 2 0.102823 0.0514115 gnus-make-hashtable 2 0.085705 0.0428525 gnus-correct-substring 4293 0.0689070000 1.605...e-05 gnus-mime-display-part 6 0.0547060000 0.0091176666 gnus-not-ignore 47401 0.0503280000 1.061...e-06 gnus-article-prepare-display 2 0.040916 0.020458 gnus-display-mime 2 0.039956 0.019978 gnus-articles-to-read 1 0.036034 0.036034 Function Name Call Count Elapsed Time Average Time ============================================================================ ========== ============ ============ gnus-topic-select-group 1 9.574398 9.574398 gnus-group-select-group 1 9.574354 9.574354 gnus-group-read-group 1 9.574346 9.574346 gnus-summary-read-group 1 9.57431 9.57431 gnus-summary-read-group-1 1 9.5743 9.5743 gnus-select-newsgroup 1 7.246213 7.246213 gnus-request-group 1 5.931924 5.931924 nnimap-request-group 1 5.931877 5.931877 nnimap-request-update-info-internal 1 5.93165 5.93165 gnus-set-difference 1 2.021512 2.021512 gnus-summary-prepare 1 1.5937109999 1.5937109999 gnus-retrieve-headers 2 1.388105 0.6940525 gnus-summary-prepare-threads 1 1.287982 1.287982 gnus-fetch-headers 1 1.269531 1.269531 gnus-cache-retrieve-headers 1 0.694133 0.694133 gnus-agent-retrieve-headers 1 0.693878 0.693878 gnus-possibly-score-headers 1 0.614546 0.614546 gnus-score-headers 1 0.613382 0.613382 gnus-score-string 1 0.588435 0.588435 gnus-get-newsgroup-headers-xover 1 0.57299 0.57299 gnus-agent-uncached-articles 1 0.5097400000 0.5097400000 gnus-agent-load-alist 2 0.4896520000 0.2448260000 gnus-cache-file-contents 4 0.4894869999 0.1223717499 gnus-agent-read-agentview 1 0.4891529999 0.4891529999 gnus-uncompress-range 1 0.271217 0.271217 gnus-sort-threads 1 0.181381 0.181381 gnus-sort-threads-1 1 0.179006 0.179006 nnheader-insert-file-contents 3 0.16395 0.0546500000 nnheader-insert-nov-file 1 0.163895 0.163895 gnus-score-string< 16424 0.1511320000 9.201...e-06 gnus-gather-threads-by-subject 1 0.118268 0.118268 gnus-put-text-property 5481 0.1178490000 2.150...e-05 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2004-06-06 20:31 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-31 10:22 Gnus vs Wanderlust Miguel 2004-05-31 23:03 ` Katsumi Yamaoka 2004-06-01 12:41 ` Lloyd Zusman 2004-06-01 14:40 ` Katsumi Yamaoka 2004-06-01 22:47 ` Lloyd Zusman 2004-06-02 12:33 ` David Abrahams 2004-06-01 15:58 ` colin.rafferty 2004-06-01 22:35 ` Miles Bader 2004-06-01 23:41 ` Katsumi Yamaoka 2004-06-02 0:13 ` Miles Bader 2004-06-02 15:26 ` colin.rafferty [not found] ` <vgvwu2q2d6m.wl-CC0PidyB7H7SDKTOTjYG+/RivMblJc010E9HWUfgJXw@public.gmane.org> 2004-06-02 17:21 ` Jochen Küpper 2004-06-03 16:39 ` Kai Grossjohann 2004-06-03 19:28 ` colin.rafferty [not found] ` <vgvwu2o1lwc.wl@paias746.morganstanley.com> 2004-06-04 5:16 ` Kai Grossjohann 2004-06-03 23:26 ` Miles Bader 2004-06-03 23:39 ` Lloyd Zusman 2004-06-04 0:05 ` Jesper Harder 2004-06-04 0:16 ` Miles Bader 2004-06-04 9:41 ` Simon Josefsson 2004-06-04 16:43 ` Karl Chen 2004-06-04 19:24 ` Kai Grossjohann 2004-06-05 10:40 ` Miles Bader 2004-06-05 15:14 ` Simon Josefsson 2004-06-06 18:35 ` Karl Chen 2004-06-06 20:31 ` Simon Josefsson
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).