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

31–40 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#31

Post by rubyn00bie »

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 thought to it:

"one sec, I just need to restart Emacs."

Followed by 30 seconds of restarting Emacs and 30 more seconds setting up the buffers. I'd definitely use Emacs but the inevitable, and uncontrollable, lockups kill it for me.

Re: Bringing GNU Emacs to Native Code (2020)

#32

Post by ashton314 »

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'd bet it's just your setup. I had one Emacs session run for almost a month straight—and that was with LSP mode running on a fairly large Elixir project. I only restarted it because I needed to restart the machine I was running it on. It was using barely over 300 MB of RAM. (Lots and lots of open buffers and whatnot.) That's not an unusual occurrence for me—and I'm not even running the native-comp branch yet!

FWIW, my Emacs init time (run `emacs-init-time`) is between 2–7 seconds, and I'm not doing anything particularly special to get that working.

I'd start out with a fresh .emacs config file and then add the packages you want with the excellent `use-package` macro, setting `:defer t` as much as possible. (Often this will be implicit if you have `:mode`, `:hook`, or `:bind` configured, if I'm not mistaken.)

It would be better if Emacs were less sensitive to how your config is setup, but alas, we live in a fallen world. You can also ask around on r/emacs and get some better tips than mine.

Re: Bringing GNU Emacs to Native Code (2020)

#33

Post by aome510 »

Really hope to see Emacs get more attention after `native-comp` branch merged to master.

Recently, I have switched to Emacs full-time (first spacemacs[0], now doom[1]). So far, it has been a great experience. Spacemacs is a bit slow but with doom and `native-comp`, I rarely encounter any performance issues.

[0]: https://github.com/syl20bnr/spacemacs

[1]: https://github.com/hlissner/doom-emacs

Re: Bringing GNU Emacs to Native Code (2020)

#34

Post by wyuenho »

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…

Sounds like you have a memory leak somewhere or some code in your emacs setup is using a lot of memory and is causing lots of gc. Turning on garbage-collection-messages and profiling memory usage will be a start to debug this.

Re: Bringing GNU Emacs to Native Code (2020)

#35

Post by didibus »

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'm not affected by this, so you might have something weird specific to your setup.

Re: Bringing GNU Emacs to Native Code (2020)

#36

Post by neolog »

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 used to get that all the time until I uninstalled some melpa package.

Re: Bringing GNU Emacs to Native Code (2020)

#38

Post by volta83 »

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 Code spawns a remote server and asynchronously updates the remote's state. VS Code remote editing experience is as good as the local one, but emacs experience is supper laggy, recurrent freezes of multiple seconds, etc. Particularly when navigating the filesystem in the remote in any modern emacs way (helm, ido, etc.). Or when auto-save happens and everything blocks for multiple seconds, etc.

---

I don't really care if native compilation makes single threaded code faster, if that single threaded code runs in the UI thread and blocks the editor for 10 seconds. Sure now it maybe blocks for 9 seconds, because you can't do much about those 9 seconds you have to wait for some IO operation to complete. But that still sucks.

Re: Bringing GNU Emacs to Native Code (2020)

#39

Post by yewenjie »

aome510 wrote: post #33

Really hope to see Emacs get more attention after `native-comp` branch merged to master. Recently, I have switched to Emacs full-time (first spacemacs[0], now doom[1]). So far, it has been a great experience. Spacemacs is a bit slow but with doom and `native-comp`, I rarely encounter any performance issues. [0]: https://github.com/syl20bnr/spacemacs [1]: https://github.com/hlissner/doom-emacs

I love Doom but it needs more documentation and more developers/maintainers. If your Elisp is good and you use Doom I would strongly recommend contributing to the code. Even if your Elisp is not good, you can totally contribute towards documentation.

Re: Bringing GNU Emacs to Native Code (2020)

#40

Post by tejuis »

didibus wrote: post #35
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'm not affected by this, so you might have something weird specific to your setup.

I've been running Emacs for almost 30 years. Stability has never been a problem and the last 5-10 years it has been rock solid for me. I can run Emacs for months without restart. Hence instability must be an issue with some packages.
Post reply on HN