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

31–40 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#31

Post by giraffe_lady »

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.

Re: Advanced techniques for reducing Emacs startup time

#32

Post by nine_k »

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.

There are mini-editors that try to mimic emacs: https://opensource.com/article/20/3/lightweight-emacs (and more which I forget).

Re: Advanced techniques for reducing Emacs startup time

#33

Post by dilap »

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, statically scoped, what else?). (Is such a thing even possible? I don't know!)

Re: Advanced techniques for reducing Emacs startup time

#34

Post by svnpenn »

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.

Re: Advanced techniques for reducing Emacs startup time

#35

Post by lizknope »

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 the time. One big problem was that vi was installed locally on every machine while Emacs was on a remote file server and there were probably 50 students typing "emacs" at the same time at the start of class all accessing the same server.

I just used vi and a bunch of terminals although later I used XEmacs in "viper" mode (vi keybindings) because it had color syntax highlighting and the split window support was cool. Vim got those features a long time ago so I just keep using vi/vim

Re: Advanced techniques for reducing Emacs startup time

#37

Post by morelisp »

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 tried this for a while but got sick of dealing with byte compilation issues. Different versions of Emacs on different systems, occasional mtime skew especially if switching branches but sometimes I think just an unlucky clock tick.

Re: Advanced techniques for reducing Emacs startup time

#38

Post by tarentel »

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.

While it can be very slow it's not something I even notice. When I start my computer, the terminal also starts on login, which means emacs starts. By the time I am ready to use it it loads instantly.

Re: Advanced techniques for reducing Emacs startup time

#39

Post by ta988 »

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.

Use the emacs server then. Start once use many.

Re: Advanced techniques for reducing Emacs startup time

#40

Post by lvass »

faho wrote: post #15
timlod wrote: post #11

I do what the author mentions as the common retort to their approach: starting an Emacs daemon (server) at boot, and opening Emacsclient when needed. In general, I always have one frame open to do actual work on, but the client is still useful if I ever navigate with a file explorer or open things through the command line (all text extensions open in Emacs). I'm not sure all the extra effort needed really does the tr…

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…

>lugging all those other buffers around

project(ile)-switch-to-buffer is your friend.

Post reply on HN