thoughts on speeding up gnus: caching the summary buffer

[Wes Hardaker <wes@hardakers.net>]

So, I have another thought for how to speed up gnus.  Significantly.
But it's probably hard.

We all know that much of the time, we simply stare at that little line
saying "Generating summary buffer" and sigh wishing we had a faster
processor.  But shouldn't it be theoretically possible to save the
contents of the summary buffer from the previous entry into the group
until next time and merely add to it?  This obviously couldn't be done
trivially.  It's likely the cache would have to contain a point
reference to every previously specified article in order to account
for thread insertions, etc.  New dummy threads would likely be a
killer.

Worst case, you could save the thread tree and possible the
insertion/marking commands into a generated .el file or something, and
then operate on that list to insert new items.

Occasionally, at least, you'd need to clear the cache as the
expired->deleted articles would no longer be available, for example,
and thus the summary buffer shouldn't technically contain them.
Moved/copied articles would have to be left marked as
'no-longer-existent' (or whatever it's called that turns the line
black), but I'd live with those lines still being present to get a
speed improvement.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett