Re: saving to nnml groups

[Sudish Joseph <sj@eng.mindspring.net>]

Kai Grossjohann writes:
> I presume using nnmh will be better because it doesn't have .overview
> files, but I don't grok the implications with regard to the active
> file.  Anyone?

In my other long and boring followup, I forgot one point, so here's
another long and boring followup.  Two for the price of one.  Whee!

IMHO, using any backend other than nnml is a lose with Gnus.  nnml is
fast mainly because it maintains the overview info.  nnfolder has
better I/O patterns than nnml/nnmh -- reading one very large file is
better than reading lots of small files on every filesystem I've seen
-- but the cost of parsing the nnfolder headers to generate the
summary still dominates in a *big* way.  

The difference is *very* noticeable even on this PPro-200, where you'd
expect slowdowns due to filesystem access to be more noticeable than
on a slower CPU.  I use nnfolder for Gcc-based archiving of mail and
Gnus crawls when entering a 200-message folder (200 isn't even _close_
to large for some of my nnml folders where I have 30 day expire times
and often do C-u SPC to search for messages).

Using a backend with NOV support is the way to go, IMHO.  (VM is so
quick because it caches similar info in the headers of the message
itself.  VM even caches summary display info, so summary generation is 
very quick -- but has the drawback of sometimes giving you weird
indentation as you delete parents.)

-Sudish