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

Bringing GNU Emacs to native code [video]

toobnix.org

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Bringing GNU Emacs to native code [video]

#61

Post by dan-robertson »

metroholografix wrote: post #32
gpderetta wrote: post #30

As a exclusive emacs user for the last 20 years, I'm quite excited; my main complain about emacs is its slow down with some more sophisticated packages. I wonder if it improves magit performance with large codebases. Pigs fly just fine with with enough thrust.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

This issue is more obvious on windows where process creation is very slow.

Emacs 26.1 should perform much better at process creation as it uses vfork on macOS instead of fork.

I don’t think that caching is an easy solution. Git can do a lot of weird things so heuristics are bound to be unreliable, brittle, or both. Furthermore the wins from caching are small for the typical users who use systems that are capable of starting processes in good time.

Re: Bringing GNU Emacs to native code [video]

#62

Post by dan-robertson »

tptacek wrote: post #44
metroholografix wrote: post #32

Earlier quoted context omitted.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

You can somewhat fix the macOS Magit perf problem --- at least the Aquamacs one --- by patching the vfork in the source. Doing that took me from keystroke-lag speed to regular interactive speed (but I've since switched to railwaycat Emacs, which I don't think has the problem, though maybe I just don't notice it).

This may have just been that you moved to railway at emacs at the same time you upgraded past 26.1 which fixed the virology thing on macOS

Re: Bringing GNU Emacs to native code [video]

#64

Post by slightwinder »

gpderetta wrote: post #27
slightwinder wrote: post #20

Earlier quoted context omitted.

I wonder whether a modern modularized architecture might be the better way to handle this. Similar to neovim where you have a backend which communicates with a detatched frontend and other backends over some rpc-mechanism. Refactor the existing emacs to work headless and become the legacy-core, while also establishing channels to attatch any other core and frontend.

An important optimization discussed in the video is to optimize through call into C code (i.e elisp->C->elisp). adding RPC at the boundaries would go in the opposite direction.

It's optimization for a single process vs multiple processes.

Additionally, when you free up your architecture and loose up the internal bindings between different areas, you sometimes can open chances for significant improvments which prior where not possible, thus still be faster with a "worse" solution.

Considering how old GNU Emacs is, how much historical problems it has and how often you hear that this and that can't be optimized for this and that reason, this seems like such a situation where loosing up would open faster roads long term.

Re: Bringing GNU Emacs to native code [video]

#65

Post by aoeuhtns »

tgbugs wrote: post #55

I have a Gentoo ebuild [0] almost working for this (I think I'm missing the step where the eln files are loaded before dumping the base image). The compile times are ... substantial. However they don't affect the development process for new code since the interpreter is always there, and I am excited to see what performance gains we will see. From an engineering perspective this is a excellent example of a direct pat…

nice, thanks for the ebuild!

Re: Bringing GNU Emacs to native code [video]

#67

Post by saagarjha »

Looks really cool! One thing I noticed was the generated code seemed to have fairly poor register allocation, looking more like it was just pulling things straight out from locals into registers and immediately storing them back. From the talk, it looks like that was what was being provided to libgccjit, but surely it could optimize that further?

Re: Bringing GNU Emacs to native code [video]

#68

Post by TeMPOraL »

gpderetta wrote: post #39
metroholografix wrote: post #32

Earlier quoted context omitted.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

that's probably one reason, but as far as I can tell, a large cost is formatting an colouring the master diff buffer when there are a lot of changes. When doing very large merges, it takes forever to refresh the buffer but aborting whatever magit is doing will leave an uncoloured but perfectly usable buffer.

Also whenever somebody accidentally commits or stages node_modules. Seriously, had that happen to me before, and Magit choked on it.

Re: Bringing GNU Emacs to native code [video]

#69

Post by TeMPOraL »

toohotatopic wrote: post #29
junke wrote: post #8

Earlier quoted context omitted.

You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…

>You can easily hack the readtable in Lisp The funny thing about lisp is that all things are easy, but yet, other eco systems offer more finished libraries.

That's the curse right here. Anyone can easily make a half-baked solution to their problem, so those solutions end up as half-baked libraries, if they get released at all.

Re: Bringing GNU Emacs to native code [video]

#70

Post by armitron »

hvis wrote: post #47
metroholografix wrote: post #32

Earlier quoted context omitted.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

Meaning, it's only really slow on macOS.

Multiple versions of macOS. And Windows. And possibly other less known systems.

Besides, why would a discerning engineer put up with magit creating all these wasteful processes knowing that most of them are redundant, regardless of performance feel? If I was a magit developer, I would surely try to fix this.

Post reply on HN