Re: Motif support

[Stefan Monnier]

>> - make the GC parallel.
>> - make the GC concurrent.
>> - use a separate thread per window-redisplay (so when redisplaying 20
>>   windows we can use 20 CPUs to update their glyph matrices).
>> - ...
>
> I think in all cases where redisplay was really slow, it was either
> due to slow Lisp being called by JIT font-lock, or by very long lines
> in the buffer, or both.  If we have several such windows, then yes,
> having that run in parallel could speed up things,

The jit-lock part can't be run in parallel (at least until we figure
out how to make ELisp code run parallel).  And with very long lines, the
problem is algorithmic, so concurrency won't help either.

> but is that really a frequent case?

None of the things I suggest above will fix all the problems, no.
Especially not the ones where things are *really* slow.  I suspect they
could help a fraction of the "middle" cases.  How much it would help
those cases, how important it is, and how it would impact other cases is
hard to tell (except maybe for the concurrent GC where the impact is
easier to predict, especially since we can draw on the experience of the
XEmacs guys with their incremental GC).

> And anyway, working on several windows in parallel will have to deal
> with the buffer-local stuff that changes global state, since each
> window generally displays a different buffer, and the display code
> makes that buffer current for the duration of time it works on a
> window.

Indeed.


        Stefan