3 ms·

I don't know: I'm running a "native compilation" branch of Emacs and everything is really fast. I'm not saying once in a rare while something chokes a bit but

I don't know: I'm running a "native compilation" branch of Emacs and everything is really fast. I'm not saying once in a rare while something chokes a bit but I made sure to eliminate some of the usual suspects in my init files (for example not launching lots of minor modes on gigantic files or on files with very long lines). In my experience Emacs, over the years, kept getting faster and faster. The "bloat", if any, is progressing way slower than CPU ares and certainly way slower than the bloat in other IDEs.

ReleaseCandidat 5y ago
The problem isn't some 'bloat' in Emacs, but that running some processes started from Emacs almost grinds Emacs to a halt. Which always has been like that, but nowadays I start way more programs in the background. About getting faster: 27 has been the first Emacs that was usable with LSP. I've been using Emacs more than 25 years now, and can't say that it is as fast as I remember it 10 or 15 years ago (on much slower hardware), but it does have _way_ more features now.
- taeric 5y ago
  My guess is this is mainly from the native json support. If you are using lsp, fast json will be a necessity. But the external processes is fixed with better use of async calls to other processes and tighter sentinel functions. Right?