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

51–60 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#51

Post by dilap »

matthews2 wrote: post #44
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…

It was subtle in my message, but my other reason for disabling was to avoid random collection pauses when using emacs.

A sibling poster recommended GCing on deactivate, which is an interesting idea!

But again, I truly haven't been able to notice any ill effects of not GCing. I tend to probably leave emacs open for maybe a few hours at a time, so I guess in that sense I'm manually GCing. :-)

Re: Advanced techniques for reducing Emacs startup time

#52

Post by dilap »

thom wrote: post #48
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))))

Ah, neat idea! Thanks!

Re: Advanced techniques for reducing Emacs startup time

#53

Post by b3morales »

> Restarting Emacs helps verify that customization will persist between sessions.

On this point I agree, but another (better, in my opinion) option is to hack in one instance and spawn a second to check the config changes you're making. You can kill and recreate the spawned one with less interruption to your work.

Re: Advanced techniques for reducing Emacs startup time

#54

Post by cheesewhizemacs »

dilap wrote: post #33
ilovecaching wrote: post #19

I gave up on Emacs and went back to Vim because of the slowness and the bugs I was encountering while using the Emacs GUI (granted a lot of them were from lsp-mode and other heavy packages). While digging for answers I was told not to use certain platforms, don't use the GUI, use the GUI, don't turn Emacs off etc. which felt like Stockholm syndrome to me. There's a lot of cargo culted config fragments like the ones y…

Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, stat…

>Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks.

Speak for yourself. Just last weekend I had a few hours with little to do, and actually wanted to do some yak shaving on my Emacs config just for the hell of it. but it works too well and I have everything the way I like it! My yak is f*kin' bald, man!

Not only have I already worked out all the little bugs that annoy me, but I've added all the features I can think of that I want!

Re: Advanced techniques for reducing Emacs startup time

#55

Post by dilap »

cheesewhizemacs wrote: post #54
dilap wrote: post #33

Earlier quoted context omitted.

Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, stat…

>Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. Speak for yourself. Just last weekend I had a few hours with little to do, and actually wanted to do some yak shaving on my Emacs config just for the hell of it. but it works too well and I have everything the way I like it! My yak is f*kin' bald, man! No…

Well, I'm jealous!

Here's my list of problems to solve on a rainy day†:

    ;; * kill-word-sp cancels ioccur mode for some reason
    ;; * after running ipython for a while, all terminal commands hang waiting for output
    ;; * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces)
    ;; * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks"
    ;; * delete-horizontal-space doesn't work w/ iedit mode
    ;; * vc-annotate doesn't properly restore window configuration
    ;; * the popup used by dumb-jump breaks when line wrapping is enabled and it's used on a wrapped line
    ;; * sometimes trying to launch a new shell just kills the old shell
    ;; * godef doesn't work when narrowed
    ;; * emacs stopped automatically recompiling .emacs wtf
    ;; * grep-ed while buffer is in loccur mode fucks things up
    ;; * undo in loccur mode messes things up
    ;; * visual-line-mode jumps around on very long lines (like paragraph long)
    ;; * parens don't overwrite properly in go-mode
    ;; * «Error running timer `auto-revert-buffers': (wrong-type-argument number-or-marker-p nil)»
    ;; * shell doesn't save history a lot of the time
    ;; * piece of shit grep edit silently fails on spaces on file names
    ;; * code-wrap is stupid with long separator lines (like "//---" for a long time)
    ;;   - sadly might be a visual line mode bug, actually...
    ;; * line highlight doesn't work after jumping to a definition
    ;; * highlight line mode doesn't work on most recent line in shell
    ;; * tendency to identify buffers by name causes bugs when renaming buffers ("stringly typed")
    ;; * subword mode doesn't think DEBUG_MEGA_GOLD is three words (in a .go file)
    ;; * if a shell command tries to open a file in emacs, and the active window is the minibuffer, the file will open into the minibuffer
Probably the biggest source of issues is two different modes not playing well with each other, which is understandable, but also something it feels like a less freeform approach to an editor might reasonably be able to do a better job of avoiding.

† To be fair, not all bugs -- some are just configuration issues I haven't figured out yet.

Re: Advanced techniques for reducing Emacs startup time

#56

Post by [deleted] »

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…

[deleted]

Re: Advanced techniques for reducing Emacs startup time

#57

Post by forgotpwd16 »

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.

For Emacs to start that slow they probably load a ton of packages if not a framework like Spacemacs. If you just load simple settings, it opens instantly.

Re: Advanced techniques for reducing Emacs startup time

#58

Post by watrup »

stjohnswarts wrote: post #45
zeendo wrote: post #21

Earlier quoted context omitted.

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.

I have something very much like this, a trivial addition to find-file. Typing C-u C-x C-f shows the recently edited filenames (with paths), and vertico + orderless makes it a joy to instantly pick the specific recent file. I get the same UI with regular find-file (C-x C-f), so the two bindings live harmoniously in my brain and fingers.

    (defun MY-consult-find-file (arg)
      "If no prefix: find-file, otherwise consult-recentf."
      (interactive "p")
      (let* ((filename
              (if (eq arg 1)
                  (call-interactively 'find-file)
                (call-interactively 'consult-recent-file)))
             )))

    (global-set-key (kbd "C-x C-f") 'MY-consult-find-file)
Before switching to vertico/orderless, I used ivy with essentially the same machinery. That worked great too.

Re: Advanced techniques for reducing Emacs startup time

#59

Post by caycep »

lizknope wrote: post #35
loloquwowndueo wrote: post #17

Eight Megabytes And Constantly Swapping :)

I was searching the comments for this! I used my first Unix machine in 1991 and started college in 1993. I knew vi but the professor used emacs and showed us how to run make from within emacs. But wow was it slow! I asked an older student and he said EMACS was just like GNU and was a recursive acronym. Emacs Makes A Computer Slow and then told us Eight Megs And Constantly Swapping. The workstations had 16MB RAM at th…

Ha! I was just thinking about that acronym. I guess the whole point of all this new hardware compute power on Apple Silicon and TSMC processes is to run emacs faster...

Re: Advanced techniques for reducing Emacs startup time

#60

Post by throw10920 »

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.

I hope this doesn't come along as aggressive but:

Do you really have a "different use case", or are you just averse to the idea of running it in the background as a daemon? Do you really need to save the 70 MB (without addons) to 200 MB (with addons) that it takes sitting there?

Unlike bloated Electron apps, Emacs doesn't actually use CPU while you're not using it - it just sits there, takes up a little memory (and even on my old 4 GB RAM ThinkPad it's not enough to actually inconvenience me), and awaits you opening a new frame with emacsclient.

Post reply on HN