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

51–60 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#51

Post by cjohansson »

volta83 wrote: post #38
DDSDev wrote: post #6

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabiliti…

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

Re: Bringing GNU Emacs to Native Code (2020)

#52

Post by db48x »

volta83 wrote: post #38
DDSDev wrote: post #6

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabiliti…

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…

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 you won’t have any problems from TRAMP.

Re: Bringing GNU Emacs to Native Code (2020)

#53

Post by volta83 »

db48x wrote: post #52
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…

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. The server can perform multiple operations, and batch them into one response.

Stuff like, "regex on all files in this directory" is performed by emacs as "list all files in directory, wait, for each file, regex that file, wait". VScode just sends the "regex all files" and the server locally handles everything, and send one update back.

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

Re: Bringing GNU Emacs to Native Code (2020)

#54

Post by db48x »

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…

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.

Re: Bringing GNU Emacs to Native Code (2020)

#55

Post by triska »

rubyn00bie wrote: post #31

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a…

You can try this code snippet to detect large variables:

https://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00...

It is a major attraction of Emacs that its inspection facilities can be easily used to automatically analyze such issues.

My expectation of Emacs is that I never have to restart it. If it crashes or fails to reliably reclaim memory, please consider filing an issue with M-x report-emacs-bug RET.

Re: Bringing GNU Emacs to Native Code (2020)

#56

Post by jamienicol »

rubyn00bie wrote: post #31

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a…

I would say it likely is your, and their, setups. But not idiocy. The way Emacs configuration works makes it very easy to break (but also very powerful)

Re: Bringing GNU Emacs to Native Code (2020)

#57

Post by lasagnaphil »

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.

It’s quite strange that the reputation for Emacs being slow hasn’t changed in decades even though hardware has advanced significantly...

Re: Bringing GNU Emacs to Native Code (2020)

#58

Post by andai »

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 switched back from VSCode to Sublime Text (despite enjoying Intellisense) due to how much more responsive the scrolling is in Sublime.

Re: Bringing GNU Emacs to Native Code (2020)

#59

Post by tgbugs »

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…

See my comment about TRAMP and file system operations from a couple of months ago for some of the underlying issues.

https://news.ycombinator.com/item?id=25626412

Re: Bringing GNU Emacs to Native Code (2020)

#60

Post by theshrike79 »

rubyn00bie wrote: post #31

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a…

I had an org-mode emacs session running 24/7 on a server for months at a time without any issues. It's something with your setup.
Post reply on HN