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

61–70 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#61

Post by samus »

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…

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 spirit of Emacs. Libuv and callbacks might be a way, but cooperative scheduling of user threads on backing threads together with structured concurrency, like Java's Project Loom is attempting, are another way.

The emergence of the LSP protocol is a very promising development in the architecture of editors and IDEs. Many things can and maybe should be passed off to background processes to handle, both to expand the feature set of every editor out there, and to increase speed and stability.

Re: Bringing GNU Emacs to Native Code (2020)

#62

Post by nxpnsv »

andai wrote: post #58
geokon wrote: post #50

Earlier quoted context omitted.

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.

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

Re: Bringing GNU Emacs to Native Code (2020)

#63

Post by TeMPOraL »

jlarocco wrote: post #26
TacticalCoder wrote: post #2

The speedup is very noticeable. Like others I'm running the "native-comp" branch of Emacs, since months, without any issue. It's now been merged into trunk and it's going to be the default: https://news.ycombinator.com/item?id=26935401 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

Eh, I don't know... I suspect the speed up depends a lot on how a person uses Emacs. I've been using it for a few months as well, and I haven't noticed any change. My start up time, as measured with 'emacs-init-time, is 0.6-0.7 seconds instead of 0.7-0.8, but that's about all I've noticed, and there hasn't been any difference in day-to-day editting. I haven't had any problems, so that's good at least.

Definitely. Depends on how much you stuff your Emacs is running. Bare-bones Emacs was generally pretty snappy, but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact.

The first thing where it usually affected me was org-mode. It runs a lot of complex text-parsing and redisplay code on the buffers, and some frequently used operations (like folding/unfolding big sections of the file, or generating agenda) would noticeably slow down with files over a couple hundred lines. That problem is now mostly gone with nativecomp - probably in part because Org Mode itself is improving its performance, but in big part because all that Elisp just runs faster across the board.

LSP mode would probably be another common case - but I only started using it on nativecomp and with the new JSON parsing module (Emacs 27 started supporting libjansson in place of whatever it was doing before). It works very well, but I imagine it was pretty unusable before these two changes.

Re: Bringing GNU Emacs to Native Code (2020)

#64

Post by volta83 »

db48x wrote: post #54
volta83 wrote: post #53

Earlier quoted context omitted.

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.

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.

Re: Bringing GNU Emacs to Native Code (2020)

#65

Post by marco_craveiro »

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 run Emacs on both Linux and Windows and I find that with more or less the same packages, the Windows Emacs tends to "slow down" after a while. I've used the profiler to track down a couple of things that were causing slowdowns (ibuffer auto refresh, etc), but still haven't quite go to the point where Windows runs as fast as Emacs. On both cases I have fairly long running Emacs sessions - around a month on Linux, when I pickup distro updates, and a week on Windows as we do mandatory reboots weekly. I recommend you try profiling to see if something shows up [1].

[1] https://200ok.ch/posts/2020-10-01_introduction_to_profiling_...

Re: Bringing GNU Emacs to Native Code (2020)

#66

Post by TeMPOraL »

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…

Definitely your setup. Long uptimes for Emacs with no performance degradation are common. Mine are typically month+. Currently, M-x uptime on my desktop (Linux) shows 33 days; on my work machine (Windows, with Emacs in WSL) it's 5 days - but that's only because I wrote a lot of tricky Elisp code to optimize my work some, and I rebooted Emacs to check it will actually work when reloaded afresh. Normally, Emacs runs uninterrupted on that machine, until Windows forces me to reboot for updates.

Startup time with nativecomp? Typically around 5 seconds on Linux, 15 seconds on WSL. If I happened to update a lot of packages before restarting (as I sometimes do, I like to clean out runtime state when I do bulk updates), then on WSL the startup goes up to about 1-2 minutes - that is, Emacs is usable in about 30 seconds, but async native compilation keeps pinning most CPU cores, so I just let it work in peace for that extra minute.

Re: Bringing GNU Emacs to Native Code (2020)

#68

Post by TeMPOraL »

marco_craveiro wrote: post #65
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 run Emacs on both Linux and Windows and I find that with more or less the same packages, the Windows Emacs tends to "slow down" after a while. I've used the profiler to track down a couple of things that were causing slowdowns (ibuffer auto refresh, etc), but still haven't quite go to the point where Windows runs as fast as Emacs. On both cases I have fairly long running Emacs sessions - around a month on Linux, wh…

I spent some time poking Emacs on Windows with a profiler too, also to no avail (few things I identified as suspect turned out to didn't matter). I eventually resigned to running Emacs under WSL1 and rendering it on VcXsrv on Windows side. It's very fast this way, though some filesystem-heavy operations are still slightly slower than they would be on Linux (that's a limitation of WSL and NTFS).

About the only issue I have with this setup is that I can't get color emojis to work using Microsoft's Segoe UI Emoji :). That, and if I want to call out to some Windows executable, I have to ensure I use :connection-type 'pipe instead of (the default) TTY in make-process, because otherwise I get a disconnected process that can't communicate with Emacs. But the latter is a very rare case (I only need it to drive the build system I use at work from Emacs, because it lives Windows-side).

Re: Bringing GNU Emacs to Native Code (2020)

#70

Post by zelphirkalt »

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…

> Why this isn’t the default I don’t know, [...]

I searched a little and found the following blog, which claims, that there are issues with it, when you do heavy data transfers, for example via many rsyncs at the same time:

https://www.anchor.com.au/blog/2010/02/ssh-controlmaster-the...

I did not test it myself. This would seem like an appropriate reason to not make it the default.

Post reply on HN