[TacticalCoder]

I upvoted you but... How comes Emacs is laggy for you? I'm running a beefy Emacs setup and it is really responsive. If anything Emacs in the nineties was "Eight Megabytes And Constantly Swapping" but... We're in 2021 now and now it's still 8 MB, so it's a rounding error (I'm only exaggerating a bit).

It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To start an entire Emacs instance from scratch (no "daemon" trickery: a real full Emacs instance), eval'ing "kill emacs" (ok, a small program if any bu still) and exiting.

I don't know which editor, in this day and age, can start and exit in 81 ms (besides vim and nano)?

Launching my full setup takes 1.1s: thousands of lines of elisp configuration.

I'm running the native-comp branch since six months (?): compilation of Emacs itself is a bit of a pain but running it is very smooth.

That's on a 6 or 7 years old Core i7 6700K / 16 GB of RAM. Hardly a speed demon (besides the NVMe M.2 PCIe 3.0 x4 SSD).

Configuration, IIRC, has got a few "tricks" to prevent the usual culprits from slowing Emacs: something to do probably with font-locking on very long lines (?) when I open such a file etc.

But it's overall more than snappy. I use ivy/avy/swiper and burntsushi's rigpgrep integrated into Emacs. Everything is not just fast but really fast.

I cannot even imagine on a modern machine like some AMD 5900X or Apple M1...

[mtalantikite]

I was a longtime Emacs user (and vim before that) and recently a project I was working on was far too laggy for me to actually work productively on in Emacs. It was largely due to me using various LSPs within Emacs -- the frontend was in TypeScript and the backend in Go, and inevitably things would grind to a halt on a 5 year old i7 MBP with 16GB of RAM.

Switched over to VSCode with as many extensions as I could find to get me close to my Emacs setup (including edamagit) and it, to my surprise, was actually very productive. I've been using VSCode now for 6 months and 15 year old me in the 90s is very mad at current me for selling out.

[da39a3ee]

I have the exact same story. Multiple LSPs in emacs was too hard to manage and seeing as some of it was typescript, much worse than the VSCode experience. Edamagit has made a very good start at emulating magit in VSCode. Still use emacs for magit though.

[the-smug-one]

It's probably too late for you :), but I use native-comp Emacs and it's blazing fast. At least lsp-mode+gopls is. I haven't gotten the chance to use this setup with Typescript's LS, but I've used gopls+clangd without slow downs.

Also, dang I miss coding in TS instead of Go.

[natrys]

I have the same experience. Being on master and nativecomp probably helps, and I also think eglot is tad smoother than lsp-mode. I am using 10 year old laptop, no friction at all with tsserver, elixir-ls or gopls. However I think the server itself is the biggest difference maker, because all hell breaks lose when I try dart/flutter even in a simple project. But to be fair, my neovim setup struggles with that too (nvim-lspconfig + nvim-compe).

[amake]

I use Dart/Flutter LSP (lsp-dart) in Emacs all the time very successfully. “All hell breaks loose” sounds like maybe you have a project cloned or created but not yet `flutter pub get`’d, in which case I have seen it act like practically every token is an error.

[natrys]

Okay, I think I am hitting some weirdness in Dart-mode itself. But it's to do with something unrelated in my config perhaps, because now I can't reproduce this with `emacs -Q`, and my dart-mode setup itself is only `(use-package dart-mode)`.

Basically even doing something mundane like C-n/C-p in a dart-mode buffer takes up a lot of memory (~800mb), which causes very high GC pressure and everything visibly stutters. Here is the `profiler-report` output just now:

https://paste.gnugen.ch/paste/5zED

But it's not helpful beyond pointing out that `line-move` when called from `next-line` for some reason is memory intensive.

[wiredfool]

LSPs and Large JSX file highlighting seem slow to me.

[throwawayboise]

Emacs is still (AFAIK) entirely single-threaded. If you are performing some operation that blocks (e.g. a network call, a shell command such as "git clone") all other windows are blocked until that completes.

I would guess if you have something like FlyMake configured for on-the-fly syntax checking, you could also get a "laggy" feeling.

Just launching and using a vanilla emacs session feels quite snappy in my experience.

[d0mine]

you don't need multiple threads to run things concurrently (such as network I/O, communicating with subprocesses) e.g., I believe url-retrieve in emacs doesn't stop the world (because there is -synchroniously version too). async is a thing

[unhammer]

magit runs git clone and such asynchronously. There's usable concurrency support in Emacs for things like network calls and external processes even though UI and pure elisp stuff is still single-threaded

[ragnese]

I know that these "works for me" discussion are often not fruitful. But, I'll ask this: have you done a several hour session of typing/programming into a JetBrains IDE? I'm claiming that on my work Macbook Pro, even just typing plain text into a file and scrolling lines in IDEA is smoother and more responsive than doing the same in Emacs.

I use the Vim plugin for IDEA and evil mode in Emacs. Even things like holding 'j' or 'k' to scroll lines is painful in Emacs compared to IDEA.

I'll admit that if I spend some hours/days in Emacs, I stop noticing it much, so it isn't THAT egregious. But if I switch back and forth, it really sucks.

[metroholografix]

Something is definitely wrong with your configuration (in a wide sense, not necessarily restricted to just the editor).

Emacs is at least an order of magnitude more responsive than IDEA (or any other JetBrains IDE). Start with a stock Emacs, no extra third party packages loaded, to get a sense of performance. There is a lot of great Emacs Lisp code out there, but the opposite is also true: Horrible code written by folks new to Emacs and Emacs Lisp, that can slow down Emacs a lot and contribute to a degraded experience. Which is why I recommend starting from scratch and incrementally adding third party code/configuration (ideally, understanding the code as you go along and avoiding packages with lots of dependencies).

[gpderetta]

Personally, I find that normally emacs latency is more than tolerable. But LSP is pretty bad, at least with clang-lsp, especially on a fairly loaded machine. I have yet to try the jit branch though.

[mumblemumble]

It's really hard to tell. The configurability of emacs is both a blessing and a curse. Since you can customize basically anything, there are all sorts of opportunities for funky config or a weird extension to slow things down.

I know, for example, that a lot of people who have tried both report that Doom Emacs is much faster than Spacemacs. That implies to me that it's not evil mode. For my part (fairly vanilla Doom setup), I find holding j/k to scroll in Doom is snappier than IntelliJ, on the same computer.

But then, I've also heard people complain that it's just the opposite on Windows, where Doom emacs is apparently just really laggy.

That said, I agree that the "works for me" discussions aren't very fruitful, and I'm definitely not here to tell you which editor to use. More observing that, what with how... emacsy... emacs is, you're definitely not alone. It's entirely possible that the problem you had is both something specific to how you had things set up, and also absolutely not at all your fault.

[creese]

If you're using HJKL to navigate more than a few lines, you're doing it wrong. Use 'search' instead.

https://www.gnu.org/software/emacs/manual/html_node/emacs/In...

[michaelcampbell]

Is it possible that your vi plugin is introducing some lag?

[jpeloquin]

> How comes Emacs is laggy for you?

I use emacs as my main editor, but as with all software it's easy to accidentally create situations where it gets laggy, regardless of hardware. Two that I've hit over the past 10 years: (1) On Windows only, movement of point in buffers with non-ascii characters lagged when said characters were visible due to frequent gc pauses. Was fixed by making emacs wait longer to do gc, and only when idle. (2) A theme that styled text with a box around it (customize-face) made buffer redisplay laggy. Not sure why; just turned it off.

[darthrupert]

Perhaps this is about MacOS vs Linux. I'm also suffering from slow emacs on mac, and no combination of flags seems to help.

Use case: open a yaml file with syntax highlightning, scroll it with the mouse. The latency should be as low as possible.

[nvarsj]

It's most likely a Mac thing. And is probably the main reason I gave up on OS X as a serious work OS, since I'm so dependent on Emacs (org-mode in particular). I hope it gets sorted one day. Apparently it has to do with certain system calls on OS X just being very slow.

[dpbriggs]

Emacs on MacOS was also laggy for me before I started using the native comp feature. It takes a while to compile but it's seriously one of the best QoL changes I've had in years.

[pcr910303]

Does Emacs native-comp work outside X (i.e. works with the Cocoa port)? I thought it only worked through XQuartz b.c. gcc can’t parse the Objective-C required for the Cocoa port…

If the Cocoa port runs well, well that changes everything to me

[rurban]

Yes, it does. I run my macOS nativecomp Emacs on it. Just the UI is not as good as on X. I have my mouse miles more than on X.

[ryukafalz]

This is my experience as well. I know it can be fast because emacs absolutely screams on my Linux machines, but it's super sluggish on the Mac I have to use for work.

[taeric]

Fwiw, I'm not seeing lag on my end doing the same. Can turn on magit blame and it still scrolls fine. :(

Opening a very large file?

Edit: I have found that if I don't reboot my Mac, the environment that a launcher emacs finds is sometimes off. Is it the same slow if you launch from a terminal versus the dock?

[darthrupert]

No, not very large.

I'm using Doom with pretty much default settings. Perhaps there's something heavy there.

[taeric]

I don't think anyone really wants to profile their editor. That said, if you have the cycles to spare, M-x profiler-start, scroll, M-x profiler-stop may have some obvious culprit.

[chalst]

I have a very underpowered Macos machine (2010 Mac mini) which faces latency problems with most things. Except Emacs. E.g., Eshell is much snappier for issuing shell commands than bash on iTerm2.

[jonnycomputer]

I don't find emacs especially laggy on mac os.

[Tehchops]

I'm using the Emacs Mac port on a modern(2019-era) MBP and it absolutely crawls when working on a large, multi-file Terraform code base.

[Decabytes]

Same. I have to work with large separated value files and it can get Emacs chugging on my Mac Book. Also any file large file that has any sort of highlighting (I.E a large xml file) can be difficult to work with.

I'm hoping that GCC emacs will resolve some of these issues. A better Elisp backend will do so much for Emacs and all of it's modes. I think one of Guilemacs goals was to have a better elisp interpreter but I'm not sure they will ever be able to keep up with all the development that has been happening on Emacs

[Tehchops]

Yea, it's quite unfortunate. Magit and Org-mode are killer, and don't really have 1:1 equivalents anywhere else.

[tngranados]

I think it's a Mac and an HDPI thing. I had to stop using emacs because it was too slow on my work MacBook Pro connected to a 4K screen. Scrolling was painful and only marginally better with nativecomp.

[b3morales]

If you are interested in continuing to use emacs, I'd suggest using the profiler to investigate. There's a good demo/depiction of doing that here: https://www.murilopereira.com/how-to-open-a-file-in-emacs/ (posted recently to HN). I think it's most likely to be something pretty specific/small in the config you're using.

I am using emacs on a Mac, often with a 4K screen, and generally have no problems. I did have a scrolling lag issue a few months ago, but it was because of a bit of code that I had added to my modeline that was doing way too much work every time something changed in the buffer. The profiler pointed me right to it.

[tngranados]

Will take a look, thanks!

[weavie]

I've recently had to dump Emacs for Vim. I found with using Rust Analyzer on Emacs, it would regularly lock up for a number of seconds. With Vim (NeoVim anyway) this does not occur.

[spamizbad]

Likely an OSX user. Emacs on my 2018 MBP is noticeably slower than my 2016 Dell XPS running Linux - despite the MBP having more ram, more clocks, and more cores.