Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The Emacs dumper dispute, or, unexec the horrible (lwn.net)
3 points by fanf2 on May 16, 2024 | hide | past | favorite | 4 comments


I'm confused about:

First, how strongly is it tied to glibc? I run emacs on FreeBSD and MacOS, and neither uses glibc. Heck, I remember building emacs on ULTRIX in the late 80s, and marveling at the clever undump thing. I don't remember having/using glibc in those days. Looking at the FreeBSD port, I don't see glibc as a build- or run-time dependency.

Second, undumping for fast startup was a thing in the late 80s with painfully slow disks and CPUs. I can't see how its still needed with today's CPUs and SSDs. I mean, electron apps are the standard these days. And, hmm, I just built emacs and temacs (the non-undumped version with "slow" loading) brings a window up in 3 seconds, about 2 seconds slower than the undumped version. (FreeBSD-current, 7 year old Ryzen, NVME)


Zaretskii

> keep as many features out of low-level C, and limit futzing with C-level internals of Lisp objects and the Lisp interpreter to the absolute minimum.

> Zaretskii's preferred solution would be to make the Elisp loader faster

Wouldn't doing so entail a lot of "futzing with C-level internals of Lisp objects and the Lisp interpreter"?


The compilation process is roughly equivalent to what Python does when it makes a .pyc file from .py file, right?

If that's so I'm kind of surprised they ever adopted the dumper approach (aeons ago) versus just compiling and saving the bytecode.

I'm probably missing something fundamental here.


(2016)

I never noticed any stability issues, as an emacs user.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: