I should perhaps also have mentioned that if emacs' garbage collection behavior was the real pause-time culprit for @amalek then that may not be any better with a JIT since the problem may be about memory loads more expensive than interpreter CPU cycles. [https://cse.buffalo.edu/~mhertz/bc-pldi-2005.pdf](https://cse.buffalo.edu/~mhertz/bc-pldi-2005.pdf) has some answers, but only for the "last level caching" hard disks/SSD data in RAM. It's possible deeper cache (like L3/TLB) thrashing is behind some `emacs` GC pauses. It's likely that much of the perceived "slowness of Lisp" is about such GC-(hw|OS) impedence mismatches. That's not fundamental, though. Nim's GC usually works fine.
In my limited experience almost no elisp packages (or users!) try to tune GC behavior, though maybe recently that's been different ([http://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/)](http://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/\)). My personal guess is that optimal settings are probably _dynamic_ , related to competition for L3, and should not be some fixed 800kB number. Maybe @Kaushalmodi knows? Anyway, editor performance tuning is a bit off the main thread topic.
