Re: overview file access when spooling and nnml/nnimap performance

[Simon Josefsson <jas@pdc.kth.se>]

Hannu Koivisto <azure@iki.fi> writes:

> I thought, some sort of database solution for storing articles would
> perhaps be the right direction.

Yes. nnml is already a step in that direction compared to nnmh.

> This brings us to nnimap.  How's its performance with some good IMAP
> server (does such things exist)?

Nnimap can't be a fast IMAP client compared to other IMAP clients,
because Gnus behaves orthogonal to several concepts used in IMAP to
speed things up. This does not mean that Gnus can't be modified to
work smoother together with nnimap, which I'm sure it will.

If you want numbers, entering a large group (~1000 articles) with
nnimap spend 20 % of the time in nnimap and 80 % in Gnus. For nnml
theese numbers are 1 % / 99 %.

This indicate that if you want better performance, you should spend
your time optimizing Gnus instead of working on a backend. The
bottleneck isn't I/O. A simple step, like moving the "range"
calculations to C (which is on the todo list, I believe) would speed
up things tremendously for very large groups (>10000 articles).