Re: db-backed mail back end

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Daniel Pittman <daniel@rimspace.net> writes:

>> There's certainly no harm to making Gnus able to handle the storage
>> needs of gargantuan archives.  Sure, knock yourself out.  But that's
>> not a problem currently being faced by more than maybe 5 people on the
>> planet, whereas every single Gnus user has to worry over the entry
>> time cost of a busy group with 900 new messages.
>
> That would be something that would be good to address first. Don't
> mistake it for the only problem, though.

It's not really an area that's been addressed before, either, so it's
an area that can be done something with.  Scoring and threading have
already been optimized several times.

There are lots of new things in Gnus that haven't been particularly
optimized.  For instance, I just did a new batch of elping, and saw
that the `seen' code called `gnus-member-of-range' once per article
displayed, which is a hight linear cost.  I separated that thing out
into its own function and saw that the `gnus-newsgroup-unseen'
computation (in a 1000 article summary buffer) took 1 second.  So I
wrote `gnus-inverse-list-range-intersection', and the computation now
takes 0.001426 seconds, says elp.

There's a lot of computational complexity in Gnus that needs more
eyes.  I think it's a safe bet that normal group entry can easily be
made a few orders of magnitude faster.  (And the
view-one-article-in-a- 200K-group can be made hundreds of orders of
magnitudes faster.)

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