Comparing mail backends

Comparing mail backends

[Kai Großjohann]

Each kind of mail backend has its own advantages and disadvantages.
Here, I'd like to learn something about speed.

Which operations are particularly slow and which operations are
particularly fast for the following backends?

  - nnmbox
  - nnbabyl
  - nnfolder
  - nnmh
  - nnml

Operations I'm thinking of:

  - Mail splitting.
  - `B c' and `B m' within a server.
  - Entering a group (ie, fetching headers).
  - Searching in a group with `M-s'.
  - Checking all groups when Gnus is started.  (I'm not sure what
    happens here, but I think at least the number of unread messages
    in each group needs to be computed.)

Feel free to add operations which I haven't thought of.

Of the above, I know nnml best, and I have seen a bit of nnfolder and
nnmh.  But I don't know how nnfolder and nnml compare when moving
messages between groups -- which one is faster?  I think fetching
headers is fastest in nnml, then comes nnfolder, and then nnmh.  Is
this correct?  nnmh seems to be very slow when Gnus is started, at
least compared with nnml; but how does nnfolder come in?

And I have no idea whatsoever about nnmbox and nnbabyl.

kai
-- 
I like BOTH kinds of music.

Searching a (mail) group

[Robert Bihlmeyer]

Hi,

>>>>> On 22 Aug 1999 14:38:54 +0200
>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) said:

 Kai> Which operations are particularly slow and which operations are
 Kai> particularly fast for the following backends?

 Kai> - nnmbox
 Kai> - nnbabyl
 Kai> - nnfolder
 Kai> - nnmh
 Kai> - nnml

[...]

 Kai> - Searching in a group with `M-s'.

wouldn't it be much faster if the backend interface offered an
optional command to search a group in a backend-specific way?

For the one-article-one-file style backends, a simple grep command is
probably one order of magnitude quicker than reading each file into a
buffer and searching it within emacs. Even for one-group-one-file
backends it could be faster to search the file buffer directly,
instead of dissecting out each article before searching.

Gnus would fall back to the usual strategy for backends not
implementing this quick-search method.

        Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: Comparing mail backends

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Each kind of mail backend has its own advantages and disadvantages.
> Here, I'd like to learn something about speed.
> 
> Which operations are particularly slow and which operations are
> particularly fast for the following backends?
> 
>   - nnmbox
>   - nnbabyl
>   - nnfolder
>   - nnmh
>   - nnml
> 
> Operations I'm thinking of:
> 
>   - Mail splitting.
>   - `B c' and `B m' within a server.
>   - Entering a group (ie, fetching headers).
>   - Searching in a group with `M-s'.
>   - Checking all groups when Gnus is started.  (I'm not sure what
>     happens here, but I think at least the number of unread messages
>     in each group needs to be computed.)
> 
> Feel free to add operations which I haven't thought of.
> 
> Of the above, I know nnml best, and I have seen a bit of nnfolder and
> nnmh.  But I don't know how nnfolder and nnml compare when moving
> messages between groups -- which one is faster?  I think fetching
> headers is fastest in nnml, then comes nnfolder, and then nnmh.  Is
> this correct?  nnmh seems to be very slow when Gnus is started, at
> least compared with nnml; but how does nnfolder come in?

Let's see...  This is just off the top of my head; I haven't done any
studies.  In order of speed, fastest first:

Mail splitting: nnmbox, nnbabyl, nnfolder, nnmh, nnml
Moving and copying: Er.

No, wait.  There's two kinds of speeds involved.  For instance, if you 
get one new mail, the overhead of loading the huge nnmbox mbox into
Emacs will be large, and nnmh will be fastest.  If you get a gazillion 
mails, nnmbox will still have to load its mbox, but after that, it'll
just append to its buffer, so it will be faster.

The same goes for pretty much all the other operations as well --
`M-s' in an nnfolder group is faster, but entering an nnml group is
faster than entering an nnfolder group.  And stuff.  Like.

Checking groups on startup is the same for all the mail backends
except nnmh, since they all have active files.

(And I do believe Quimby got, er, slashdotted.  I mean it only has
16MB of RAM, and each PHP-httpd takes 8MB.  Swap-o-rama.  And I
probably forgot to put a MaxClients thing into the startup file.

It had a load of 49 before it stopped talking to me.

Wait!  I got a prompt!  Yay!

I should put more RAM into the beast.)

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

Re: Searching a (mail) group

[Lars Magne Ingebrigtsen]

Robert Bihlmeyer <e9426626@stud4.tuwien.ac.at> writes:

> wouldn't it be much faster if the backend interface offered an
> optional command to search a group in a backend-specific way?

It would, but defining a, er, scatter-gather sort of backend searching 
interface thingie sounds like work.

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

Re: Comparing mail backends

[Wes Hardaker]

>>>>> On 24 Sep 1999 20:52:10 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> (And I do believe Quimby got, er, slashdotted.  I mean it only has
Lars> 16MB of RAM, and each PHP-httpd takes 8MB.  Swap-o-rama.  And I
Lars> probably forgot to put a MaxClients thing into the startup file.

Lars> It had a load of 49 before it stopped talking to me.

Lars> Wait!  I got a prompt!  Yay!

Lars> I should put more RAM into the beast.)

Ya think?

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: Comparing mail backends

[Lars Balker Rasmussen]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:
> >>>>> On 24 Sep 1999 20:52:10 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:
> Lars> (And I do believe Quimby got, er, slashdotted.  I mean it only has
> Lars> 16MB of RAM [...]
> 
> Lars> I should put more RAM into the beast.)
> 
> Ya think?

At least now seems to be the perfect time to do it!

(Bye-bye plans of 256MB in my homebox).
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk