My Lisp Experiences and the Development of GNU Emacs (opens in new tab)

My biggest problem with Emacs today is responsiveness. This is partly due to lack of threading, partly due to slow execution of Elisp code, and partly due to poor data structures/database use in the back end (e.g. for maintaining indexes). I have to throttle semantic analysis from CEDET just to have a usable system and I avoid other features because they just take too long to run.

My Emacs session has been running for two weeks and I have 560 open buffers, which amounts to a memory usage of 620 MB. I don't think it's unreasonable for most every interactive operation to be instant.

I don't blame Lisp for the slowness, except insofar as the language promotes the use of data structures like simple lists that eventually create bottlenecks, and that the Elisp implementation is not very fast compared to something like SBCL.

Maybe I'm missing the joke, but Emacs was famous for bringing multi-megabyte machines to their knees and garbage collecting for minutes. The joke was that emacs stood for "eight megabytes and constantly swapping".

I find that emacs ruby-mode slows to a crawl when editing a 6000 line ruby file. Now I realize the file is way too long ( these things take time to fix / refactor ), any tips on getting it to be more responsive?

Who doesn't believe that?

I'll see your emacs as "best proof" and raise you node.js - sure it's C++ underneath, but few people are going to argue that interpreted javascript is "close to machine code". For some tasks, elisp is a clunky and slower than writing a shell script or small python/ruby/javascript process to do the same work. I don't even want to mention the horror that is finding correct documentation for a given version of emacs lisp compared to any other software or language.

disclosure: I'm currently writing a small node server in emacs. I'm happy with both as they are very responsive, but emacs does chug occasionally like a bro at a frat house.