I use Emacs daily for 80% of my work and its performance is not an issue.
Speak for yourself. I also use Emacs daily for 80% of my work and while performance is OK, I would definitely welcome any improvements. Areas where I notice subpar performance are especially:
* paging through or searching in very large buffers (such as large log files), particularly with syntax highlighting enabled
* re-indenting large regions
Also, modes like eterm always feel a bit laggy.
And all the tiny little delays add up. It does matter to me whether skipping to the end of a large file takes 200 ms or 20 ms -- only a little bit but again, it adds up.
I wonder to what extent such a rewrite could be done incrementally. For example, can the redisplay code (which is a big, complicated mess, as one commenter in the article points out) be left in C for a start and "only" the elisp-facing code be ported? If so, this sounds like a viable approach.
I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.
Good point. Adding multi-threading while keeping the existing elisp compiler would definitely improve responsiveness, maybe enough so to turn the issues I mentioned into non-issues. That said, the proposed approach has the potential to kill two birds with one stone: add multi-threading AND improve raw performance.
The problem with multi-threading in emacs isn't a lack of libraries to support threads, as CL would supply, but rather the complexities of synchronization of a large existing codebase, which porting to CL would have no effect.
Speak for yourself. I also use Emacs daily for 80% of my work and while performance is OK, I would definitely welcome any improvements. Areas where I notice subpar performance are especially:
* paging through or searching in very large buffers (such as large log files), particularly with syntax highlighting enabled
* re-indenting large regions
Also, modes like eterm always feel a bit laggy.
And all the tiny little delays add up. It does matter to me whether skipping to the end of a large file takes 200 ms or 20 ms -- only a little bit but again, it adds up.
I wonder to what extent such a rewrite could be done incrementally. For example, can the redisplay code (which is a big, complicated mess, as one commenter in the article points out) be left in C for a start and "only" the elisp-facing code be ported? If so, this sounds like a viable approach.
I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.