8 ms·

JIT Compilation for Emacs Lisp

180 points by deng 9y ago

jwr 9y ago
It's fantastic that people want to tackle the complexity that is Emacs Lisp and work on a JIT for it. It might not be the most fashionable thing these days, but a faster Emacs would make life significantly better for countless developers. I am having high hopes for this project.
- systems 9y ago
  Completely agree Also add to this the trend or rise language servers .. emacs can continue to be used as a solid ide alternatives And .. guile emacs hopefully one day Any work to improve and re-use emacs is good for everyone
  - eadmund 9y ago
    > And .. guile emacs hopefully one day I'm hoping for a Common Lisp emacs, myself. Scheme as specified just isn't a big enough language, and if you pick one of the better implementations (e.g. Racket, which is awesome), then it's not really Scheme anymore (e.g. Racket, which is really its own language by now).
    - jnordwick 9y ago
      I would still call it Scheme, just not R*RS Scheme.
- didibus 9y ago
  I hate to admit it, but the slowness of Emacs is why I avoid it. A good JIT which hopefully speed it up would be amazing.
  - dorp 9y ago
    ELISP is a pretty fast language, faster than VimScript or JS for sure. EDIT: Also, Emacs is bloated is bloated because it's not just a editor its's an Web Browser, Email Client, News Reader, Music Player and File Manager. If people want a light emacs, they can go use uEmacs or become the last JEDi.
    - quotemstr 9y ago
      It's a good glue language, like Python. Better than Python in the sense that its internal representation is based on tagged values instead of ubiquitous pointers: for example, 43243 represents itself and isn't a pointer to a some reference-counted PyObject representing an int. And because Emacs Lisp a lisp, you get extensive syntactic malleability that you can use to build DSLs and convenience facilities. Elisp is actually a very nice little language.
      - armitron 9y ago
        Your absence from emacs-devel is felt, there was so much excitement when you were around.
    - yzmtf2008 9y ago
      “Fast” is really a meaningless and vague word. What specific part of emacs lisp is faster than javascript in what regard? For what it’s worth, V8 among with some other JITs are some of the fastest engines in the world: https://arewefastyet.com/#machine=29&view=breakdown&suite=asmjs-ubench https://arewefastyet.com/#machine=29&view=breakdown&suite=as...
      - earenndil 9y ago
        > V8 among with some other JITs are some of the fastest engines in the world I find that doubtful, when the jvm is so close to native code in terms of performance, and mozilla said that wasm (or was it asm.js? Forget which) was still 50% slower theoretically than native code.
        9y ago
  - agumonkey 9y ago
    Which use cases are slow for you ? you used it on large code base or parsed cpp source ? A quicker emacs would be neat, but most of the time emacs gets speed from flexibility (it might be slow but I can automate something) and design decision (magit for instance blows 99% of the fastest git interfaces) ps: one part that realize is that I don't like emacs daemon, and even curated my setup on windows (probably the culprit) takes a few seconds. It's not slow but often I want a buffer right away so I use notepad u_u; stupid I know.
    - kqr 9y ago
      Also worth mentioning that whatever is slow, profile it to find out why. Sometimes only the smallest tweak is necessary to get it up to speed again. (Different tweaks for different configurations, so can't be a default.) For interactive use, profiling is as simple as M-x profiler-start, doing what causes the slowdown, and then M-x profiler-report.
      - agumonkey 9y ago
        Good point, emacs has a lot of tooling (edebug and tracing too) but it's rarely demonstrated, and since emacs is so large.. In my case there's nothing slow but IO, I should try on another windows laptop with a faster SSD (mine is low grade) to see what is what.
    - confounded 9y ago
      With an Emacs server/daemon, it loads faster than Vim for me.
      - agumonkey 9y ago
        I would happily agree but I lost the one emacs and 119422 buffers mindset. I get lost in my own shit. I should spend time improving my ibuffer grouping but even then.. I like the idea of pop, edit, kill (which causes my harm).
        alexhutcheson 9y ago
  - zeveb 9y ago
    Honestly, I don't much notice emacs being slow, esp. given how much it's doing for me under the hood. One key thing is to always always always use emacs in dæmon mode, rather than starting up a new emacs for each file (as would be done with vi). With an always-running emacs instance, start-up time is no longer a factor, and the editor itself is plenty fast enough once it's running.
    - junnan 9y ago
      I use a nox emacs with minimum .emacs for quick editing in terminal. Its startup time is comparable to vi.
  - ams6110 9y ago
    I don't find emacs slow, and I spend most of my day in it. What is annoying, is that when it blocks, all frames and windows block.
    - peterbecich 9y ago
      Maybe this will improve in Emacs 26: https://www.reddit.com/r/emacs/comments/7ta67n/is_emacs_multi_threaded/ https://www.reddit.com/r/emacs/comments/7ta67n/is_emacs_mult...
taeric 9y ago
I'm torn. On the one hand, I definitely want emacs to be faster as it does more and more for me. However, I also want more and more of the things that folks are doing in emacs to be driven by other processes. Preferrably ones I can use outside of emacs to get answers. As an example, I get that emacs would have to parse the entire buffer I'm in in order to syntax highlight as I'm typing. For that, I think this is going to be required. However, emacs should be able to offload to another process to look up external symbols. GLOBAL is the tool I use nowdays, and updating the tags database or looking up symbols is something that should be getting heavy lifting in an external process. Or am I looking at things the wrong way?
- gkya 9y ago
  IIRC tags databases are big files that need to be parsed and operated on via Elisp, so a faster interpreter would be beneficial there. I don't think a faster interpreter would hinder integration of external tools, given often they do not only provide speed, but also quality software with proven longevity.
  - taeric 9y ago
    Traditional ones, yes. However, modern tag databases are just that, databases. Sending a query to a database to find all callers and such can be offloaded to another process easily enough. Note that this isn't really that new, for the modern tag. Cscope was already an external command. And you already offloaded the tag creation to an external process. I see very little need for the tag navigation to all be in elisp. The final selection, of course, can still be in elisp. Since that will be user input driven.
    - gkya 9y ago
      Emacs now has C extension support, which might be helpful in fast interactions with external tools too.
- sedachv 9y ago
  > GLOBAL is the tool I use nowdays, and updating the tags database or looking up symbols is something that should be getting heavy lifting in an external process. What do you use for GLOBAL? ggtags.el works like you describe (calls start-file-process to start a GLOBAL process).
bjoli 9y ago
Cool! Speeding up Emacs is always welcome. I will bring the obligatory guile Emacs rant: I am very much biased,but guile Emacs is very much a viable option IMO. Guile3.0 will be natively compiled (or at least jitted), and the work Andy Wingo is putting into guile is just amazing. The guile codebase is nice, and most of the hard work integrating it into Emacs is already done. The elisp runtime has some optimization work left, but it seems to be quite a lot of low hanging fruit. Guile is a very nice scheme implementation for those who are brave enough to leave the warmth of elisp.
xorcist 9y ago
What happened to Guile? It seemed like a promising way forward that didn't stray too far from elisp.
- bjoli 9y ago
  I am also hoping for guile Emacs, but I am pretty sure I am hoping in vain. The amount of bikeshedding going on in emacs-devel even for small non-controversial changes can sometimes take humorous proportions. I have used guile-emacs and back then even org-mode ran fine. Elisp-compatibility is very close to 100%, and the runtime is getting better by the week (guile3 will do native compilation!), but nothing will ever be enough. So instead of having a runtime not bound to Emacs, with all the cons that would have with libraries and such (Imagine a guile-orgmode that contained the vital parts of org scirptable in guile without Emacs), we are stuck with a language tethered to an editor bound to be just an extension language.
fulafel 9y ago
> Even better than this would be to improve the calling convention so that all calls are less expensive. However, because a function can be redefined with different arguments, it is tricky to see how to do this efficiently. Clojure has a compiler option toggle for this called direct linking. It just says that functions can't be redefined (unless they are marked redef using a metadata key). You can also mix and match libraries compiled with or without direct linking, for example the core library uses this compile switch.

180 points by deng 9y ago

jwr 9y ago

It's fantastic that people want to tackle the complexity that is Emacs Lisp and work on a JIT for it. It might not be the most fashionable thing these days, but a faster Emacs would make life significantly better for countless developers. I am having high hopes for this project.

systems 9y ago
Completely agree Also add to this the trend or rise language servers .. emacs can continue to be used as a solid ide alternatives And .. guile emacs hopefully one day Any work to improve and re-use emacs is good for everyone
- eadmund 9y ago
  > And .. guile emacs hopefully one day I'm hoping for a Common Lisp emacs, myself. Scheme as specified just isn't a big enough language, and if you pick one of the better implementations (e.g. Racket, which is awesome), then it's not really Scheme anymore (e.g. Racket, which is really its own language by now).
  - jnordwick 9y ago
    I would still call it Scheme, just not R*RS Scheme.
didibus 9y ago
I hate to admit it, but the slowness of Emacs is why I avoid it. A good JIT which hopefully speed it up would be amazing.
- dorp 9y ago
  ELISP is a pretty fast language, faster than VimScript or JS for sure. EDIT: Also, Emacs is bloated is bloated because it's not just a editor its's an Web Browser, Email Client, News Reader, Music Player and File Manager. If people want a light emacs, they can go use uEmacs or become the last JEDi.
  - quotemstr 9y ago
    It's a good glue language, like Python. Better than Python in the sense that its internal representation is based on tagged values instead of ubiquitous pointers: for example, 43243 represents itself and isn't a pointer to a some reference-counted PyObject representing an int. And because Emacs Lisp a lisp, you get extensive syntactic malleability that you can use to build DSLs and convenience facilities. Elisp is actually a very nice little language.
    - armitron 9y ago
      Your absence from emacs-devel is felt, there was so much excitement when you were around.
  - yzmtf2008 9y ago
    “Fast” is really a meaningless and vague word. What specific part of emacs lisp is faster than javascript in what regard? For what it’s worth, V8 among with some other JITs are some of the fastest engines in the world: https://arewefastyet.com/#machine=29&view=breakdown&suite=asmjs-ubench https://arewefastyet.com/#machine=29&view=breakdown&suite=as...
    - earenndil 9y ago
      > V8 among with some other JITs are some of the fastest engines in the world I find that doubtful, when the jvm is so close to native code in terms of performance, and mozilla said that wasm (or was it asm.js? Forget which) was still 50% slower theoretically than native code.
      - 9y ago
- agumonkey 9y ago
  Which use cases are slow for you ? you used it on large code base or parsed cpp source ? A quicker emacs would be neat, but most of the time emacs gets speed from flexibility (it might be slow but I can automate something) and design decision (magit for instance blows 99% of the fastest git interfaces) ps: one part that realize is that I don't like emacs daemon, and even curated my setup on windows (probably the culprit) takes a few seconds. It's not slow but often I want a buffer right away so I use notepad u_u; stupid I know.
  - kqr 9y ago
    Also worth mentioning that whatever is slow, profile it to find out why. Sometimes only the smallest tweak is necessary to get it up to speed again. (Different tweaks for different configurations, so can't be a default.) For interactive use, profiling is as simple as M-x profiler-start, doing what causes the slowdown, and then M-x profiler-report.
    - agumonkey 9y ago
      Good point, emacs has a lot of tooling (edebug and tracing too) but it's rarely demonstrated, and since emacs is so large.. In my case there's nothing slow but IO, I should try on another windows laptop with a faster SSD (mine is low grade) to see what is what.
  - confounded 9y ago
    With an Emacs server/daemon, it loads faster than Vim for me.
    - agumonkey 9y ago
      I would happily agree but I lost the one emacs and 119422 buffers mindset. I get lost in my own shit. I should spend time improving my ibuffer grouping but even then.. I like the idea of pop, edit, kill (which causes my harm).
      - alexhutcheson 9y ago
- zeveb 9y ago
  Honestly, I don't much notice emacs being slow, esp. given how much it's doing for me under the hood. One key thing is to always always always use emacs in dæmon mode, rather than starting up a new emacs for each file (as would be done with vi). With an always-running emacs instance, start-up time is no longer a factor, and the editor itself is plenty fast enough once it's running.
  - junnan 9y ago
    I use a nox emacs with minimum .emacs for quick editing in terminal. Its startup time is comparable to vi.
- ams6110 9y ago
  I don't find emacs slow, and I spend most of my day in it. What is annoying, is that when it blocks, all frames and windows block.
  - peterbecich 9y ago
    Maybe this will improve in Emacs 26: https://www.reddit.com/r/emacs/comments/7ta67n/is_emacs_multi_threaded/ https://www.reddit.com/r/emacs/comments/7ta67n/is_emacs_mult...

taeric 9y ago

I'm torn. On the one hand, I definitely want emacs to be faster as it does more and more for me. However, I also want more and more of the things that folks are doing in emacs to be driven by other processes. Preferrably ones I can use outside of emacs to get answers. As an example, I get that emacs would have to parse the entire buffer I'm in in order to syntax highlight as I'm typing. For that, I think this is going to be required. However, emacs should be able to offload to another process to look up external symbols. GLOBAL is the tool I use nowdays, and updating the tags database or looking up symbols is something that should be getting heavy lifting in an external process. Or am I looking at things the wrong way?

gkya 9y ago
IIRC tags databases are big files that need to be parsed and operated on via Elisp, so a faster interpreter would be beneficial there. I don't think a faster interpreter would hinder integration of external tools, given often they do not only provide speed, but also quality software with proven longevity.
- taeric 9y ago
  Traditional ones, yes. However, modern tag databases are just that, databases. Sending a query to a database to find all callers and such can be offloaded to another process easily enough. Note that this isn't really that new, for the modern tag. Cscope was already an external command. And you already offloaded the tag creation to an external process. I see very little need for the tag navigation to all be in elisp. The final selection, of course, can still be in elisp. Since that will be user input driven.
  - gkya 9y ago
    Emacs now has C extension support, which might be helpful in fast interactions with external tools too.
sedachv 9y ago
> GLOBAL is the tool I use nowdays, and updating the tags database or looking up symbols is something that should be getting heavy lifting in an external process. What do you use for GLOBAL? ggtags.el works like you describe (calls start-file-process to start a GLOBAL process).

bjoli 9y ago

Cool! Speeding up Emacs is always welcome. I will bring the obligatory guile Emacs rant: I am very much biased,but guile Emacs is very much a viable option IMO. Guile3.0 will be natively compiled (or at least jitted), and the work Andy Wingo is putting into guile is just amazing. The guile codebase is nice, and most of the hard work integrating it into Emacs is already done. The elisp runtime has some optimization work left, but it seems to be quite a lot of low hanging fruit. Guile is a very nice scheme implementation for those who are brave enough to leave the warmth of elisp.

xorcist 9y ago

What happened to Guile? It seemed like a promising way forward that didn't stray too far from elisp.

bjoli 9y ago
I am also hoping for guile Emacs, but I am pretty sure I am hoping in vain. The amount of bikeshedding going on in emacs-devel even for small non-controversial changes can sometimes take humorous proportions. I have used guile-emacs and back then even org-mode ran fine. Elisp-compatibility is very close to 100%, and the runtime is getting better by the week (guile3 will do native compilation!), but nothing will ever be enough. So instead of having a runtime not bound to Emacs, with all the cons that would have with libraries and such (Imagine a guile-orgmode that contained the vital parts of org scirptable in guile without Emacs), we are stuck with a language tethered to an editor bound to be just an extension language.

fulafel 9y ago

> Even better than this would be to improve the calling convention so that all calls are less expensive. However, because a function can be redefined with different arguments, it is tricky to see how to do this efficiently. Clojure has a compiler option toggle for this called direct linking. It just says that functions can't be redefined (unless they are marked redef using a metadata key). You can also mix and match libraries compiled with or without direct linking, for example the core library uses this compile switch.