Hacker News Reader

Hacker News

Comment by jancsika | Hacker News Reader

Full thread

jancsika

Should add a surreptitious cryptocurrency miner to keep your cpu/gpu warm and cozy.

View on HN

I think emacs already does that fine

And it doesn't even use electron. It was just ahead of time.

Not without better concurrency support.

Your comment suggests that you are aware of this, but for those that don't know, elisp did gain something resembling concurrency support in 26.1: https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

Too bad porting[1] Emacs to Guile wasn't finished (even seems abandoned), could have improved speed and multithreading (and even better extensibility too).

[1] https://www.emacswiki.org/emacs/GuileEmacs

I know about ram and don't have a computer handy but processor too?

have you actually used emacs on a cpu made in the last 20 years and found it to be slow?

compared to vim or bash, it is cpu intensive. compared to any of the graphical apps that come with a mac, it is easier on the cpu (and on RAM).

have you actually used emacs on a cpu made in the last 20 years and found it to be slow?

Yes. Early 2015 Macbook Pro.

It's hella slow to start up, of course, even on my 2017 mbp. Chugs when scrolling depending on active modes, too.

Launch it as a daemon and instantly connect via emacsclient.

I should do that, but it seems like a Band-Aid solution to the real problem which is poor performance.

Launching `emacs -Q` (=no daemon, start without init.el) – which is equivalent to a typical way of starting `vi` or (shudder) `nano` – opens essentially instantly. A more complicated init.el/.emacs will take longer to start, but I fail to see how this is 'poor performance'.

Emacs is meant to be open all the time. As it is way more than a simple Editor.

You can do all the CLI tasks inside Emacs.

Emacs Vanilla takes less than a second to open in my t430(2011)

I use emacs basically all day and so my comment was partially in jest. I find the following things to be slow:

1. Large files

2. Anything synchronous and blocking that takes a little too long can be frustratingly slow. This often isn’t entirely the fault of emacs (e.g. if it is slow because an external program is slow) but async isn’t done for everything so sometimes things block and you can’t do anything while they are working. This is particularly annoying if the external program provides eg auto-completion

3. Running a macro a large number of times

4. Building the completion list when finding files (I think this is a combination of an issue with the extension for finding files and how it reads a directory and just reading a very large directory over nfs)

5. Sometimes it becomes slow enough that the visual lag between key press and character-on-screen is annoyingly large

we used to call it: Eight Megabytes And Currently Swapping. but those days are long gone...

Compared to VS Code? Come now.

Spacemacs with a mostly standard config has similar load times as VSCode (2-3 seconds)...

I’ve never understood the load time argument about IDEs, I probably restart my IDE whenever I do os upgrades every other week or so. This is true when I use IntelliJ, Emacs, or VS Code. Any of these could take 30s or longer to start for all I care.

The issue with VS Code is that it’s more memory hungry than google chrome. More than once I’ve caught it using half a gig of memory, with various instances of flow using up to a gig on top of that.

I prefer using one editor for every task. This means both coding and quick config edits or jotting down notes. So while I often keep an instance up for hours, I also open and close it frequently enough that load time is enough of an issue.

I personally do not use one editor for everything. To each their own.

Emacsclient would solve this issue for you though.

Vim solves this issue for me, since it loads nearly instantaneously even loaded down with plugins.

There's nothing standard about Spacemacs. It's a tremendously useful premade config, but it's not indicative of the performance of the Emacs environment.

I know, but featurewise it's on par with VSCode with things like git integration and auto-suggestion etc. so I feel like it's a fair comparison.

Do you think vanilla Emacs with the same amount of packages would be much faster (without getting into tricks like a daemon)?

Reply on news.ycombinator.com