
JIT Compilation for Emacs Lisp - deng
http://tromey.com/blog/?p=982
======
jwr
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.

~~~
didibus
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.

~~~
agumonkey
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.

~~~
twblalock
I've noticed that pasting large amounts of text (> 1000 lines) can make it
grind to a halt for several minutes. I don't know if it's due to the mode I'm
in.

~~~
agumonkey
Few editable systems are happy with 1K lines. I remember a discussion where
only one editor was happy dealing with that, all other became sluggish.

~~~
barrkel
1k lines does not stress many editors. It only stresses emacs when the major
mode is doing lots of stuff to highlight and format.

I regularly used other editors on C files with 30k+ lines, 15 years ago when
machines were slower.

Emacs' real weakness is an over-reliance on regexes for highlighting and poor
integration with sources of semantic and symbolic information for richer
highlighting, editing and browsing. That, and synchronous operations for the
same.

~~~
signa11
> 1k lines does not stress many editors.

but folks here are talking about _each_ line >1k characters, not total number
of lines in a file...

------
bjoli
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.

------
taeric
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?

~~~
barrkel
I agree. I think language servers are the way to go, ideally leveraging the
same lexer and parser as a production compiler / interpreter to avoid
mismatches.

~~~
taeric
I'm also torn on that idea. I think multiple parsers and such are healthy for
the ecosystem. Mainly because I am heavily swayed by the dangers of
monocultures.

So, to that end, I think it is healthy that there are at least 3 powerful
javascript implementations. I just wish there was more equalization in the
marketplace for them.

And, I cannot argue against the merits of a language server. Having a single
one would be more efficient in many ways. I just find our fixation on "not
reinventing the wheel" to be detrimental in many ways. I'd rather we were
"don't get stuck with a monoculture."

And I say this as someone that highly respects the LISP community. It is
impressive how much you can do with really old libraries there.

------
fulafel
> 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.

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

~~~
bjoli
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.

