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

111–120 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#111

Post by samus »

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…

30 seconds for startup is really weird. Mine starts in a few seconds, and is far from fully customized. Initializing the language servers of open buffers takes by far the most time.

Emacs has many solutions to restore buffers. I use `desktop`, which is built-in. Use whichever you like, I really can't tell you the pros/cons.

Have you ever tried setting the garbage collection treshold to a large value? There's definitely no use for it during startup. It might make sense though to trigger it in a hook after startup.

Re: Bringing GNU Emacs to Native Code (2020)

#112

Post by agumonkey »

stjohnswarts wrote: post #106
agumonkey wrote: post #74

Earlier quoted context omitted.

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

If you're have a problem with performance in vscode 95/100 times it's memory not cpu bound. Obviously emacs uses less memory than vscode, at least at base configuration.

Maybe, it's still incredible to think that memory pressure would create that much latency. And I'm not that picky, I use a hp48 calc (on which lag is almost a feature). I'm just shocked when people say emacs is sluggish while vscode flies.

Re: Bringing GNU Emacs to Native Code (2020)

#113

Post by anaerobicover »

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…

Indeed. It does not need precisely multithreading, but at least asynchrony, which is to allow side tasks to not block the main function of editing text. I have low familiarity with emacs internals, but I can assume there is an event loop, which is a basic form of this.

Perhaps this needs be used more, or there is another mechanism to be developed allowing tasks to be interrupt/resumed in priority service to the editing functions. A key example may be mode line refresh: this certainly must happen on the main thread, but it ought not block other more important items.

Re: Bringing GNU Emacs to Native Code (2020)

#114

Post by anaerobicover »

wtetzner wrote: post #91
zelphirkalt wrote: post #76

Earlier quoted context omitted.

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 mo…

In terms of LSP, I don’t think there’s anything particularly novel about it. It’s really only better than other similar protocols in the sense that it is gaining in popularity. I.e., the biggest thing that was missing is consensus on a shared protocol. In terms of the protocol itself, I suspect it’s actually worse than a lot of other ones.

> I suspect it’s actually worse than a lot of other ones.

Choosing JSON to communicate certainly could have been more wisely decided. Moreover since sending entire file contents across for some queries, what a waste.

Re: Bringing GNU Emacs to Native Code (2020)

#115

Post by samus »

pixel_fcker wrote: post #20

It makes LSPs usable for me on my desktop 5950x. Still a bit laggy on my laptop.

Unfortunately, Emacs won't really benefit since it is a (mostly) single-threaded application by design. But that sweet 5950x should definitely speed up running dozens of language servers and indexers at the same time :-D

Re: Bringing GNU Emacs to Native Code (2020)

#116

Post by cbsmith »

da39a3ee wrote: post #100
TeMPOraL wrote: post #63

Earlier quoted context omitted.

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…

> but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact. I'm not sure I understand what you mean there. Unless those third-party packages are scheduling tasks on the event loop then they should not be impacting performance of your other operations. Just having lots of things installed and activated doesn't affect performance.

It's not having lots of things installed. It's actually using them. Basically how much custom elisp is running in your buffer.

Re: Bringing GNU Emacs to Native Code (2020)

#117

Post by cbsmith »

pama wrote: post #77
volta83 wrote: post #64

Earlier quoted context omitted.

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 a…

I was going to say, there is a way to do the server side logic with Emacs... ;-)

Re: Bringing GNU Emacs to Native Code (2020)

#118

Post by samus »

zelphirkalt wrote: post #76
samus wrote: post #61

Earlier quoted context omitted.

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 mo…

It indeed isn't. Some Emacs packages use that approach, and others are well-known to employ Unix utilities to do the legwork. Maven and Gradle both have daemon modes. Unfortunately, all these integrations are custom, so there is no chance for it to take off. Ycmd is also worth mentioning.

What really made the difference is that VS Code uses LSP to integrate languages. Instead of dozens of ad-hoc integrations, there is one unified way to integrate a language now, and Microsoft's backing ensured there is an ecosystem for it from day one.

Not all is rosy though, mind you. LSP uses JSON/RPC after all. Also, we are touching the Microsoft world here, which means that standard adherence is not necessarily a given[0].

[0] https://www.reddit.com/r/vim/comments/b3yzq4/a_lsp_client_ma...

Re: Bringing GNU Emacs to Native Code (2020)

#119

Post by zucker42 »

cjaybo wrote: post #109
zucker42 wrote: post #95

Earlier quoted context omitted.

> All this stuff runs in the UI thread. Braindamaged. Calling this "braindamaged" is hardly fair; I'm sure this decision was made ~35 years ago when it made more sense.

Forgive my ignorance, but why would doing all of the application work on a single thread make more sense 35 years ago?

The first consumer processors with multiple cores came out around 2005. Before there were multiple cores in consumer machines, there was no reason to implement concurrency in a way that would scale to multiple cores.

Re: Bringing GNU Emacs to Native Code (2020)

#120

Post by dmd »

TacticalCoder wrote: post #24
ashton314 wrote: post #4

Earlier quoted context omitted.

I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project. Note: this was on an Intel mac; anyone with an M1 tried this yet? I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not…

Can't help as I'm on Linux (also I use ivy/avy/counsel and not consult/marginalia/vertico).

Out of curiosity, why did you reply?
Post reply on HN