Re: What's the problem?

[Ted Zlatanov]

On 11 Dec 2003, address@hidden wrote:

> Ted Zlatanov <address@hidden> writes:

>> > Some questions are (1) are there only a few points within gnus
>> > that represent most of the annoying delays
>> 
>> Hashtable lookups, list traversals, and arithmetic.  Those three
>> show up all over the place, and they are generally not mutually
>> dependent when done on separate articles.
> 
> No, that's not what I meant -- those sorts of operations may in
> aggregate represent the bulk of the cpu time spent, but no single
> operation actually takes very long.
> 
> I'm more concerned with what entry points into gnus (I mean, user
> commands) hang for a long time.  Find those, and if there are only a
> few of them, see if they can be split up using a pseudo-threading
> framework or something.

I'll list the pieces I know best.  There are probably others.

- getting new mail, read/write existing mail
  - interacting with network backends
    - nnimap: medium read, slow write
    - nntp: fast read
    - nnrss: slow initial read
  - interacting with local backends: nnml, nnmaildir, etc.
  - spam-splitting

- sending mail

- building summary buffers
  - retrieving articles from overview data
  - scoring
  - building threads
  - spam-splitting (for backends that don't get new mail, e.g. nntp)

- detecting and processing spam
  - recognizing spam (connects with spam-splitting above)
  - remembering spam with internal or external programs

- tracing article threads back to a folder (gnus-registry)
  - look up registry hashtable, look through a list for each
    reference ID and examine each cell closely
  - look up, modify, and store back registry hashtable entry

>> > I don't know.  A framework like the above could pretty simply
>> > handle the I/O bound portion too, though.
>> 
>> Remember the auto-save (over NFS or Tramp) problem I mentioned.  I
>> don't think it can be done the way you propose, but I'll be happy
>> to be proven wrong.
> 
> Sure; I hate auto-save delays too (even more annoying is the address@hidden
> purposeful-delay-to-give-an-error-message autosave does when it
> can't write a file), but I suppose fixing them would require
> low-level changes to emacs.

I'll be the first one in line if those changes ever happen.

Thanks
Ted