Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advanced techniques for reducing Emacs startup time

blog.d46.us

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#41

Post by nine_k »

svnpenn wrote: post #34
nine_k wrote: post #26

I honestly don't understand the point. Emacs (much like VSCode or Idea) is a tool that I use for everything, all day. I don't see a point in shutting it down, except for upgrading the version. Its startup time of, say, 15 or even 30 seconds (if you start many language servers) is only paid once, when I log in. So I run it in server mode, and emacsclient start instantly, as a GUI window, or in a terminal, with all the…

> Its startup time of, say, 15 or even 30 seconds Jesus. I use Gvim, which starts in less than a second. When I'm done editing, I close it. The only app I generally leave open, is browser. How people can justify such awful performance is beyond me, and why I will never, ever use Emacs.

How much code intelligence does GVim give you? Code navigation? Type information? Refactoring?

The question is actually about IDE features which take longer time to initialize, mostly in the non-Emacs code such as language servers.

Emacs with only built-in plugins loads from scratch instantly on my machine. But if I only need to do a simple quick edit, I can equally invoke vi :) (Which I regularly do, to keep my basic vi skills current.)

Re: Advanced techniques for reducing Emacs startup time

#42

Post by stjohnswarts »

nine_k wrote: post #26

I honestly don't understand the point. Emacs (much like VSCode or Idea) is a tool that I use for everything, all day. I don't see a point in shutting it down, except for upgrading the version. Its startup time of, say, 15 or even 30 seconds (if you start many language servers) is only paid once, when I log in. So I run it in server mode, and emacsclient start instantly, as a GUI window, or in a terminal, with all the…

I mean 90% of the problem is overcome just by running emacs server.

Re: Advanced techniques for reducing Emacs startup time

#43

Post by stjohnswarts »

giraffe_lady wrote: post #31
nine_k wrote: post #26

I honestly don't understand the point. Emacs (much like VSCode or Idea) is a tool that I use for everything, all day. I don't see a point in shutting it down, except for upgrading the version. Its startup time of, say, 15 or even 30 seconds (if you start many language servers) is only paid once, when I log in. So I run it in server mode, and emacsclient start instantly, as a GUI window, or in a terminal, with all the…

Just different use cases then. Emacs isn't my main coding tool these days but I still use it for single-file editing, and I close it when I'm done with that file. The start up time does matter to me somewhat. Though I have a pretty simple config for the same reason and it's not bad enough for me to spend time on. I do keep an eye on it though.

"emacs --daemon" and emacs-client are key to solving this scenario

Re: Advanced techniques for reducing Emacs startup time

#44

Post by matthews2 »

dilap wrote: post #28

I just disable emacs garbage collection entirely. Fast startup, no more random pauses, haven't noticed any problems yet. (This was probably like a year ago.) (On the other hand, emacs is never quite problem free, so maybe this is introducing problems and I just haven't noticed.) I have tons of customizations and lots of packages, but be as religious as reasonable about lazy loading. $ time emacs --eval '(save-buffers…

Instead of totally killing the garbage collector, you can effectively turn it off during startup by setting gc-cons-threshold to a large number, and then restore it after init. The article touches on this but they don't increase it very much and restore it at the end of init.el (emacs-startup-hook runs later).

early-init.el:

  (setq gc-cons-threshold most-positive-fixnum)
  (add-hook 'emacs-startup-hook (lambda ()
    (setq gc-cons-threshold (* 2 1024 1024))))

Re: Advanced techniques for reducing Emacs startup time

#45

Post by stjohnswarts »

zeendo wrote: post #21
jonathanstrange wrote: post #6

My Emacs takes ages to start but for a reason. It takes most of the time to automatically load every file I've ever edited into a buffer. Finding the right buffer is much faster for me than navigating the filesystem, and whenever I use bookmarks they're outdated too quickly or I can't remember them. I guess my habit is the equivalent of piling papers on a desk.

I like this approach and almost considered doing it after reading this - or probably only opening the last few hundred files - but then I realized that the recent file list probably gets me 99% of the way there. Is there anything you get by opening the files that you wouldn't get by opening files from the recent file list instead?

well I usually have trouble remembering the exact name of the file I was editing 2 months ago? :) . Now if there is a plugin to have rg look through the last few hundred files that I've edited that would be a game changer.

Re: Advanced techniques for reducing Emacs startup time

#46

Post by golergka »

svnpenn wrote: post #34
nine_k wrote: post #26

I honestly don't understand the point. Emacs (much like VSCode or Idea) is a tool that I use for everything, all day. I don't see a point in shutting it down, except for upgrading the version. Its startup time of, say, 15 or even 30 seconds (if you start many language servers) is only paid once, when I log in. So I run it in server mode, and emacsclient start instantly, as a GUI window, or in a terminal, with all the…

> Its startup time of, say, 15 or even 30 seconds Jesus. I use Gvim, which starts in less than a second. When I'm done editing, I close it. The only app I generally leave open, is browser. How people can justify such awful performance is beyond me, and why I will never, ever use Emacs.

Looks like you're judging a fish by it's ability to climb a tree.

Re: Advanced techniques for reducing Emacs startup time

#47

Post by ParetoOptimal »

unhammer wrote: post #18
faho wrote: post #15

Earlier quoted context omitted.

I prefer having a clean instance so I can open up an emacs for the project I'm currently working on, as opposed to lugging all those other buffers around and leaving any changes intact. So I don't use a daemon. And these "advanced techniques" aren't really all that hard - 90% is just using use-package, which has a number of other advantages. It can be set up to install uninstalled packages, so you can do a self-insta…

I no longer let use-package install things. I use the same init on different computers, so sometimes I would have to wait for use-package to install things on startup and sometimes melpa would be down or some package would be a newer version and require new deps and use-package doesn't handle such situations. It's very little gain for a lot of hassle. Instead I just check all of emacs.d/elpa into the same git repo. T…

I use use-package with nix but disable package.el being able to install anything.

This way I get fast startup and the download problem you mention doesn't happen.

If nix isn't your thing, I used to do the same with straight.el by checking in .emacs.d/straight and disabling install by setting repos to nil.

Re: Advanced techniques for reducing Emacs startup time

#48

Post by thom »

dilap wrote: post #28

I just disable emacs garbage collection entirely. Fast startup, no more random pauses, haven't noticed any problems yet. (This was probably like a year ago.) (On the other hand, emacs is never quite problem free, so maybe this is introducing problems and I just haven't noticed.) I have tons of customizations and lots of packages, but be as religious as reasonable about lazy loading. $ time emacs --eval '(save-buffers…

I like to do this to ensure GC happens occasionally, when I focus away from Emacs:

    (add-function :after
                  after-focus-change-function
                  (lambda () (unless (frame-focus-state)
                               (garbage-collect))))

Re: Advanced techniques for reducing Emacs startup time

#49

Post by thom »

jonathanstrange wrote: post #6

My Emacs takes ages to start but for a reason. It takes most of the time to automatically load every file I've ever edited into a buffer. Finding the right buffer is much faster for me than navigating the filesystem, and whenever I use bookmarks they're outdated too quickly or I can't remember them. I guess my habit is the equivalent of piling papers on a desk.

I find 'ido-use-virtual-buffers' a much more lightweight way of achieving this, FWIW. I'm sure similar features are available for Ido alternatives.

Re: Advanced techniques for reducing Emacs startup time

#50

Post by mcbuilder »

svnpenn wrote: post #34
nine_k wrote: post #26

I honestly don't understand the point. Emacs (much like VSCode or Idea) is a tool that I use for everything, all day. I don't see a point in shutting it down, except for upgrading the version. Its startup time of, say, 15 or even 30 seconds (if you start many language servers) is only paid once, when I log in. So I run it in server mode, and emacsclient start instantly, as a GUI window, or in a terminal, with all the…

> Its startup time of, say, 15 or even 30 seconds Jesus. I use Gvim, which starts in less than a second. When I'm done editing, I close it. The only app I generally leave open, is browser. How people can justify such awful performance is beyond me, and why I will never, ever use Emacs.

Said like such a vimmer. Anyway, my real comment is that I used vim exclusively for 5 years before switching to Emacs for like the past 9. I use evil mode to emulate vim of course. I'd run a server and ZZ or :wq as soon as I finished editing the file. My colleague, a regular Emacs user, commented how I drive emacs like vim in pair-coding.

Now with vterm I run Emacs all the time, my buffers stay mostly open. Anyway, the best manner to use the tool is probably dictated by the tool, but I will tell you I am not bothered at all for my Doom Emacs 2 second starting time every few hours / days.

Post reply on HN