[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's the problem?

From: Ted Zlatanov
Subject: Re: What's the problem?
Date: Thu, 11 Dec 2003 13:39:39 -0500
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]