3 ms·

Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?

by S4M 9y ago

taeric 9y ago
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.
- aardvark179 9y ago
  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.
  - taeric 9y ago
    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.
- krylon 9y ago
  > 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.
  - taeric 9y ago
    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.
username223 9y ago
I don't see any advantage of Emacs going from the current mark-sweep collector to a copying collector. I don't notice GC pauses using Emacs, and even after being up for weeks, I don't notice it bloating from memory fragmentation. It also seems like a lot of work to change a large, mature codebase to work with a GC that moves objects. EDIT: Apparently my experience is not universal -- see below: https://news.ycombinator.com/item?id=15803046 https://news.ycombinator.com/item?id=15803046

Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?

by S4M 9y ago

Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?

taeric 9y ago

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.

aardvark179 9y ago
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.
- taeric 9y ago
  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.
krylon 9y ago
> 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.
- taeric 9y ago
  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.

username223 9y ago

I don't see any advantage of Emacs going from the current mark-sweep collector to a copying collector. I don't notice GC pauses using Emacs, and even after being up for weeks, I don't notice it bloating from memory fragmentation. It also seems like a lot of work to change a large, mature codebase to work with a GC that moves objects. EDIT: Apparently my experience is not universal -- see below: https://news.ycombinator.com/item?id=15803046 https://news.ycombinator.com/item?id=15803046