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

21–30 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#21

Post by zeendo »

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?

Re: Advanced techniques for reducing Emacs startup time

#23

Post by R0flcopt3r »

vegai_ wrote: post #16
mickeyp wrote: post #14

Earlier quoted context omitted.

You can instruct Emacs (with or without emacsclient) to open in a terminal with: emacsclient -nw That way, you'll connect to your Emacs server but using a terminal Emacs (even if your main instance is GUI Emacs)

Oh, I wonder how I had missed that option. Thanks!

or you use vterm-mode as your terminal and then you simply open a file like you do now, except now it opens in place of the vterm-mode buffer. Close the buffer like you would do, and you're back to vterm.

Re: Advanced techniques for reducing Emacs startup time

#24

Post by faho »

hprotagonist wrote: post #20
faho wrote: post #9

Ideally use-package would simply be included in emacs, so you could rely on it. Apparently they are getting close: https://github.com/jwiegley/use-package/issues/282 Until then, I have this in my init.el to install it if necessary: ;; Install use-package because that installs everything else (unless (package-installed-p 'use-package) (package-refresh-contents) (package-install 'use-package)) (require 'use-package)

except that use-package, by itself, does not install anything . NOTE: use-package is not a package manager! Although use-package does have the useful capability to interface with package managers (see below), its primary purpose is for the configuration and loading of packages. (I use straight, which interfaces nicely into use-package.)

> except that use-package, by itself, does not install anything.

It can be configured to install things (by using the builtin package.el): https://jwiegley.github.io/use-package/keywords/#ensure-pin

> You can use use-package to load packages from ELPA with package.el. This is particularly useful if you share your .emacs among several machines; the relevant packages are downloaded automatically once declared in your .emacs. The :ensure keyword causes the package(s) to be installed automatically if not already present on your system (set (setq use-package-always-ensure t) if you wish this behavior to be global for all packages)

So if all you need is package.el (and there's a good chance that's the case), you can just

    (setq use-package-always-ensure t)
and your configuration will now install the packages if you copy it to a new system.

Re: Advanced techniques for reducing Emacs startup time

#25

Post by kaushalmodi »

This post felt like a deja vu, because I had read this earlier back in Nov 2017 :). The HN mods should add the 2017 year to the title. That said, for people who haven't read this post earlier, this post shares some great tips! I like the one about deferring packages using `use-package`.

Because this is an old post, references like Spacemacs are now quite dated. Folks prefer Doom Emacs nowadays (though I don't use either of them).

Re: Advanced techniques for reducing Emacs startup time

#26

Post by nine_k »

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 amenities of an IDE already in place.

Re: Advanced techniques for reducing Emacs startup time

#27

Post by nine_k »

jonpalmisc wrote: post #13

I’d like to see something like this but for speeding up Emacs at runtime. I have a 0.25s startup time with packages but my Emacs struggles when using lsp-mode or eglot in large C++ projects. I’ve been using Sublime Text lately but would like to get back to Emacs.

Is it Emacs, or the language server? It would be interesting to profile.

Re: Advanced techniques for reducing Emacs startup time

#28

Post by dilap »

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-kill-emacs)'
    real 0.21s
Not bad, but still very noticable, which is annoying.

About half of it is unavoidable.

    $ time emacs -q --eval '(save-buffers-kill-emacs)'            
    real 0.11s
(-q disables reading the config file.)

(With default GC settings, startup is about 300ms.)

Re: Advanced techniques for reducing Emacs startup time

#29

Post by kkfx »

Honestly I'll rather prefer a bigger multi-threading/MP usage to reduce deadlocks because Emacs is an ecosystem, even reducing it's startup time to the minimum it will never be like Vim, those who do not use EXWM simply can run Emacs daemon at their desktop startup to much with the client Vim startup time, BUT those who use Emacs as a DE like me I bet all prefer far less freezing like during packages upgrades, feeds fetching, Gnus etc vs the not really relevant startup time...
Post reply on HN