Hacker News Reader

Comment by taeric | Hacker News Reader

This is asked in the thread, though I'm not sure I saw a good answer, yet.

Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help.

Now, this implies that a new one would, ipso facto, be faster. That is not guaranteed. But, garbage collectors have gotten quite effective in modern times. Extra memory helps, of course.

View on HN

There are two ways a new GC might be helpful. It might reduce the length of any individual pause (though normally at the expense of total overall pauses) and it might reduce total memory usage by compacting the heap and being a precise rather than a conservative collector.

The current emacs GC can introduce long pauses, so I’d be happy to see something which improved Thant, and I have seen annoying increased memory usage in long emacs processes so experiments in this area would be welcome.

I'm curious how you get long pauses. I only really see giant pauses when I do a sync process call that takes longer than I expected. So, updating GLOBAL tags, for example.

> Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help.

Is that an actual problem, though?

Maybe I just don't push Emacs that far, but I have never felt GC performance to be much of a problem on even remotely capable hardware (say, anything at least as fast as a Raspberry Pi model 2).

Plus, Emacs allows the user to configure the frequency at which the garbage collector kicks in. Tweaking gc-cons-threshold has been entirely sufficient for my needs.

I personally doubt it is much of a problem. However, that doesn't mean I personally think nobody should try it. Will be interesting to see if any results follow.

To your point, though, I suspect better async processing would be of much greater benefit.

Reply on news.ycombinator.com