Hacker News new | ask | show | jobs
by goalieca 3083 days ago
Emacs starts reasonably quick and it is written in a very extensible language.
2 comments

The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon.

I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.

Emacs was critisized, heck even banned from uni labs back in the day, because it used too much RAM. Now the time has come for us to mock Electron based editors :).

> I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.

I believe that was actually due to a quirk in the way CSS animations worked in Chrome. It was fixed by changing to setInterval which is what was used before. GIF animations were proposed, but AFAIK never actually used.

Here's the GH issue: https://github.com/Microsoft/vscode/issues/22900

I don't know if this is still true, but for many years emacs used a horrible hack called "unexec" to obtain this startup performance.

https://lwn.net/Articles/673724/

That sounds similar to the "snapshot" feature Atom is using.
It was only true for glibc as well, and its no longer true as unexec got ripped out of glibc recently as only emacs was using it.