haskell-language-server
haskell-language-server copied to clipboard
haskell
Is disabling idle GC measurably better?
I would think that an idle GC would be well-suited for an IDE. There are long periods where the application is not going anything which could be used for GC.
The argument presented by @ndmitchell (here) is that "in a build system", there are usually external tasks which are running for over 0.3s. However, as we have observed in ghcide, most actions run for a very short amount of time (see haskell/ghcide#503)
What happens in my experience when using ghcide is that hovering triggers a GC which causes a noticeably pause with a large heap.
We should actually come up with a metric to measure which one is better. These flags were added in haskell/ghcide#329 by @pepeiborra who claimed that it reduced hover time by 4s, but why would that be the case? The way to investigate is to record an eventlog I think.
Related to haskell/ghcide#512 as well.
The problem is that idle GC performs a major GC of the very large ghcide surviving set, which can take several seconds every single time. An eventlog confirming this would be good.
-I ⟨seconds⟩ Default: 0.3 seconds in the threaded runtime, 0 in the non-threaded runtime In the threaded and SMP versions of the RTS (see -threaded, Options affecting linking), a major GC is automatically performed if the runtime has been idle (no Haskell computation has been running) for a period of time. The amount of idle time which must pass before a GC is performed is set by the -I ⟨seconds⟩ option. Specifying -I0 disables the idle GC. For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. Also, it will mean that a GC is less likely to happen when the application is busy, and so responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant delay, and too small an interval could adversely affect interactive responsiveness.
