Am 30.07.20 um 07:31 schrieb Compl Yue via Haskell-Cafe:
And now I realize what presuring GC in my situation is not only the large number of pointers (TVars), and at the same time, they form many circular structures, that might be nightmare for a GC.
Cycles are relevant only for reference-counting collectors. As far as I understand http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_contr..., GHC offers only tracing collectors, and cycles are irrelevant there.
I'm still curious why the new non-moving GC in 8.10.1 still don't get obvious business progressing in my situation. I tested it on my Mac yesterday and there I don't know how to see how CPU time is distributed over threads within a process, I'll further test it with some Linux boxes to try understand it better.
Hmm... can GHC's memory management fragment? If that's the case, you may be seeing GC trying to find free blocks in fragmented memory, and having to re-run the GC cycle to free a block so there's enough contiguous memory. It's a bit of a stretch, but it can happen, and testing that hypothesis would be relatively quick: Run the program with moving GC, observe running time and if it's still slow, check if the GC is actually eating CPU, or if it's merely waiting for other threads to respond to the stop-the-world signal. Regards, Jo