Re: What's the problem?

[Miles Bader <miles@lsi.nec.co.jp>]

Ted Zlatanov <tzz@lifelogs.com> writes:
> > IOW, it's annoying for the gnus programmer, but very easy for the
> > emacs implementation.
> 
> Well, that's the rub, isn't it?  Simon and I, being Gnus programmers,
> would like Emacs to provide something better than the current
> framework so the pain will be spread out instead of concentrated on
> us.  I think that improvements to Emacs would be beneficial to far
> more people than improvements to Gnus, also.

Of course.  It's just that past a certain point (e.g. providing _real_
threading), the changes to emacs are insanely complex and intrusive.

The sort of awkward `pseudo-threading' framework I gave an example of,
although it's annoying for the application programmer, is I think
relatively _less_ annoying than the sort of massive emacs changes
required for true threading.

If the number of places where you really _need_ it are fairly few, I
think it makes more sense to put the complexity in those places.
My impression is that this is the case; indeed, for me it's basically
like 2-3 operations in gnus, and that's it (most other time-consuming
commands use external processes in the background to do their work).

Now, any of my assumptions could be wrong, in which case maybe the
calculation is different, but...

> > 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 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 !@#$%!
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.

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'