Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing GNU Emacs to Native Code (2020)

arxiv.org

Post reply on HN
Print view View original

71–80 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#71

Post by dw-im-here »

cjohansson wrote: post #51
volta83 wrote: post #38

Earlier quoted context omitted.

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

I agree about this issue, maybe in the distant future this could be fixed as well but where will VSCode be at that stage? Probably even more miles ahead, due to MS funding. When there is good async support in Emacs a lot of packages would need to be rewritten. However I prefer Emacs anyday over VSCode, I am very productive in Emacs because I'm used to doing almost everything in it

vscode doesn't even support multiple monitors, it's far behind in many areas.

Re: Bringing GNU Emacs to Native Code (2020)

#72

Post by zelphirkalt »

volta83 wrote: post #53
db48x wrote: post #52

Earlier quoted context omitted.

A lot of this is down to configuration. For example, you say “Emacs TRAMP uses one ssh connection per command”, but that’s only true if you’re not using the ControlMaster SSH option. Add this to your ~/.ssh/config file: ControlMaster auto ControlPersist yes ControlPath ~/.ssh/control/%C Then run mkdir -p ~/.ssh/control/, if you haven’t already. Why this isn’t the default I don’t know, but once configured correctly yo…

I have this, yet I still see emacs sending individual I/O operations over SSH and blocking on their completion. Everything that requires remote file system interaction is super slow. Emacs just seem to be doing lots of individual I/O operations. VScode has a remote server that batches them before updating over the network. The client sends operations to the server and queries the server for updates asynchronously. Th…

> The same happens for pretty much every modern feature (git status, diffs, blames and updates, autocompletion, correctness checks / intellisense, etc.).

Could it be a configuration issue in parts at least? Because it does start to sound like it. For example git status has never been slow for me in Emacs, except for huge diffs with lots of changes in lots of files. Same for diffs. I know, that autocompletion depends on the language and tools used for it and what things are checked for possible auto completion entries. It is possible to limit autocompletion to only use some sources, or to make it use a language server for some languages. When developing Rust, Python or TypeScript in Emacs, I did not experience slow correctness checks (I assume you mean type checks and unused variable kind of stuff.).

Re: Bringing GNU Emacs to Native Code (2020)

#73

Post by kqr »

samus wrote: post #61
volta83 wrote: post #38

Earlier quoted context omitted.

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

Emacs is definitely capable of multithreading. Still using a single thread might actually be a boon because it simplifies the programming model. Right now, Elisp code can work under the assumption that there is only one thread accessing editor state at the same time. Disentangling this is probably going to be difficult, but the Emacs folks are probably smart enough to come up with something that matches with the spir…

With a few exceptions, I don't think moving stuff into the background promotes speed and stability. It makes it way easier to get away with reductions to both.

Re: Bringing GNU Emacs to Native Code (2020)

#74

Post by agumonkey »

geokon wrote: post #50
darthrupert wrote: post #25

Earlier quoted context omitted.

Emacs has been pretty slow in editing, ever since Visual Code came along to set the bar higher. Good thing that Emacs is back in the game though, that editor has heart.

last I tried VSCode there was a noticeable input lag (keystroke to character on screen). Is there some trick to fix this? I found it incredibly distracting. In Emacs... Magit is instantaneous while orgmode tangle/export is embarrassingly slow - but never a dealbreaker anecdotally eshell has some of the lowest latencies as well https://danluu.com/term-latency/

I couldn't even type 2 chars in vscode on a 2nd gen i5. To be fair it's been decades since I've experienced that amount of delay. Thanks I guess

Re: Bringing GNU Emacs to Native Code (2020)

#75

Post by da39a3ee »

harles wrote: post #42

Genuine question: why is this on Arxiv? It seems like a design document in the format of a research paper.

Your question comes across as uncharitable and I suspect you have no relevant experience. Without implying that your question has any validity, if you have an academic career, you need publications. Therefore it's the opposite of what you imply. We want people to feel welcome to write up all sorts of computing achievements in academic forums, because that is what will help the authors be able to carry on doing what they are doing and thus allow us to benefit from their work.

Re: Bringing GNU Emacs to Native Code (2020)

#76

Post by zelphirkalt »

samus wrote: post #61
volta83 wrote: post #38

Earlier quoted context omitted.

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

Emacs is definitely capable of multithreading. Still using a single thread might actually be a boon because it simplifies the programming model. Right now, Elisp code can work under the assumption that there is only one thread accessing editor state at the same time. Disentangling this is probably going to be difficult, but the Emacs folks are probably smart enough to come up with something that matches with the spir…

To outsource things step-by-step to lightweight processes seems to be a good incremental way to disentangle. Perhaps one could protect access to resources not initially invented by Emacs packages (Emacs core?) and make Emacs query a separate process, without a package knowing about that, so that it channels all communication to the separate process. Then deprecate directly the resource at some point and offering a more direct way of communicating with the separate process. Finally removing the state in the main process. I think more Emacs internals knowledgeable people would need to judge this idea.

Is there anything in the communication of LSP making the LSP stand out from any other protocol? (I really mean the protocol, not the infrastructure on which it is used.) Other than that it is quite an old idea to have things at the ready running in a separate process. This time it is applied to editors, completion, type checking and other features. In general this simplifies making use of multi-core systems. Watch any Joe Armstrong talk about it. The question is, why it was not thought of before, or perhaps, if it was, then why it was not done before.

Re: Bringing GNU Emacs to Native Code (2020)

#77

Post by pama »

volta83 wrote: post #64
db48x wrote: post #54

Earlier quoted context omitted.

This varies from command to command, but M-x grep literally just runs the program grep on the remote machine. It doesn’t enumerate the files and search each one individually. If you’re using something other than M-x grep, then sure, it might be written badly.

The command I use is `M-x find-grep`. I also use `helm`, `ido`, etc. to navigate the file system and they are all super slow.

You might have already tried this: I’ve had fantastic performance starting a remote emacs server and using emacs (often in terminal mode) through ssh. It certainly has a one time cost: setup your local terminal for all keys to go through, and sync your init files. I still use tramp for certain rare cases but most work happens on 3 remote and 1 local machine with four different emacs servers running, and a couple of additional non-development machines that I simply ssh into from within emacs shells.

Re: Bringing GNU Emacs to Native Code (2020)

#79

Post by the_duke »

tejuis wrote: post #41
the_duke wrote: post #18

Every time I try Emacs I get annoyed by it's slowness and go back to vim and VS Code. This might entice me to build it and try out my Emacs Doom setup again.

There are number of things you can do to improve your situation. Obviously you should not have packages loaded that you don't rely use. There are also ways to perform "lazy" loading, so that memory image is minimal until a package is really needed. I'm not using this myself. My usage model is such that I only start one Emacs and use emacsclient to add files for editing from terminals. Emacs is running all the time (w…

My problem is really not the startup/loading time, but the regular stutters and long latency for input and commands.

I need my editor to "feel" really smooth and instant during editing. Emacs just never gives me that experience.

I think many long-time Emacs (and Jetbrains IDEs, for that matter) users just don't notice how laggy it is because they are so used to it, or are not very latency sensitive.

Re: Bringing GNU Emacs to Native Code (2020)

#80

Post by darthrupert »

nxpnsv wrote: post #62
andai wrote: post #58

Earlier quoted context omitted.

I switched back from VSCode to Sublime Text (despite enjoying Intellisense) due to how much more responsive the scrolling is in Sublime.

Same here, maybe it’s only in my head, but for me subl is just better.

It is massively better in latency than any other editor I've tried. No surprise, since I believe it's C++.

Unfortunately sublime's plugin ecosystem isn't very lively.

Post reply on HN