While this sounds like an interesting and ambitious project, I don't think it will ever get off the ground. I use Emacs daily for 80% of my work and its performance is not an issue. The author seems a bit too optimistic that a GCC plugin can automate the majority of the port to CL -- it may provide a nice start but finishing the port will me a considerable amount of tedious work and from the perspective of an Emacs user, I suspect either they won't notice the change or the change will introduce new bugs.
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.
The lack of proper multithreading has bit me many times when I try to use Emacs as an email client--start talking to the IMAP server, and your whole Emacs process takes a break. Can't edit anything, we're stuck until it either finishes or you hit C-g.
I use IMAP over SSL with Gnus, and the actual talking-to-the-network is asynchronous (handled by another UNIX process). The slow part is generating the summary buffer on large groups.
(BTW, if you use IMAP with Gnus, I highly recommend using a local IMAP server instead. You can sync to your remote IMAP server with offlineimap. This speeds up Gnus enormously for me; reading my Maildir directly from Gnus is too slow to be usable, but reading it through a local IMAP server makes reading my inbox instantaneous.)
I run a dedicate instance for Gnus for exactly that reason. Has the added benefit of keeping me from being distracted by a simple (Emacs) window change when I'm focused in my other instances.
Comments
While this sounds like an interesting and ambitious project, I don't think it will ever get off the ground. I use Emacs daily for 80% of my work and its performance is not an issue. The author seems a bit too optimistic that a GCC plugin can automate the majority of the port to CL -- it may provide a nice start but finishing the port will me a considerable amount of tedious work and from the perspective of an Emacs user, I suspect either they won't notice the change or the change will introduce new bugs.
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.
> I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.
Or perhaps it's the other way around: adding multithreading to Emacs Lisp would make performance no longer a problem.
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.
The lack of proper multithreading has bit me many times when I try to use Emacs as an email client--start talking to the IMAP server, and your whole Emacs process takes a break. Can't edit anything, we're stuck until it either finishes or you hit C-g.
I use IMAP over SSL with Gnus, and the actual talking-to-the-network is asynchronous (handled by another UNIX process). The slow part is generating the summary buffer on large groups.
(BTW, if you use IMAP with Gnus, I highly recommend using a local IMAP server instead. You can sync to your remote IMAP server with offlineimap. This speeds up Gnus enormously for me; reading my Maildir directly from Gnus is too slow to be usable, but reading it through a local IMAP server makes reading my inbox instantaneous.)
I run a dedicate instance for Gnus for exactly that reason. Has the added benefit of keeping me from being distracted by a simple (Emacs) window change when I'm focused in my other instances.