The Emacs dumper dispute [LWN.net]

The Emacs dumper dispute

Posted Dec 1, 2016 22:06 UTC (Thu) by eduard.munteanu (guest, #66641)
Parent article: The Emacs dumper dispute

Odd. I thought Emacs had a server mode which allowed thin clients to be spawned quickly when invoked. Why the dumper? Doesn't the server cater for startup delay issues?

to post comments

The Emacs dumper dispute

Posted Dec 2, 2016 12:25 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

The server is decades newer than the dumper. Plus, the server was distinctly unreliable until a relatively short number of decades ago, and you still have to wait for emacs --daemon to start now and then. (Though, frankly, mine takes ten minutes to start anyway because I have so many buffers open... a 10s delay to load Lisp as well would be totally ignorable to me, but not to everyone, and most certainly not to the byte-compilation phase of Emacs building, which starts Emacs hundreds of times.)

The Emacs dumper dispute

Posted Dec 2, 2016 16:36 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (4 responses)

I also object as a matter of principle to the idea that we should forgive long startup times generally and paper over the delays by structuring every application as a client-server system. What if *everyone* did this? We'd live in a world where no program you ran would ever really leave memory. It's an incredible waste of system resources. Plus, with client-server setups, it's hard to get things like security, environment variable propagation, reliable daemon restarts, process priority, file descriptor inheritance, etc. right, and everyone who writes one of these daemon systems has to deal with these fiddly issues alone.

You could argue that dumping is also papering over performance problems, but at least dumping does so in a way that doesn't have negative global performance implications. I wish kernel-level checkpoint and restart were widely available: if the system managed the dumping instead of individual processes like Emacs having to do this work, we'd be better off.

The Emacs dumper dispute

Posted Dec 4, 2016 17:19 UTC (Sun) by mstone_ (subscriber, #66309) [Link] (1 responses)

But, who cares? The size of code on a modern system is negligible; we're buying gigabytes of RAM for data and the code size is pretty much an afterthought. It would be a shame if people focused on making it possible to free a couple of megabytes here or there instead of focusing on correctness or performance or something else with more tangible benefit.

The Emacs dumper dispute

Posted Dec 4, 2016 19:21 UTC (Sun) by viro (subscriber, #7872) [Link]

You are making several completely unwarranted assumptions:

1) that data structures won't take a lot more than the code would

2) that *all* developers can tell their arse from elbow and memory leak from decent behaviour.

Note that relatively few participants can introduce leaks faster than everybody else manages to fix them...

The Emacs dumper dispute

Posted Dec 4, 2016 18:09 UTC (Sun) by drag (guest, #31333) [Link]

> What if *everyone* did this?

There are a lot of benefits to this approach besides speeding up start-up.

Gnome-terminal, tmux, emacs... these are a few of the things that have this model of having a 'server'. If you want to expand the definition somewhat this is not much far off of what Chrome and Firefox browsers are following.

Seems to be a nice way to go.

The Emacs dumper dispute

Posted Dec 4, 2016 22:12 UTC (Sun) by eduard.munteanu (guest, #66641) [Link]

In that case, we should agree that the real culprit is the compiler/runtime. Caching JIT/AOT compilers can and do solve the startup delay issue for other languages, and it looks like that's what's missing here.