[georgewsinger]

> Compact regions, allowing better control over garbage collection in the presence of large heaps containing many long-lived objects.

Can someone explain how this feature works and/or how much impact it has on Haskell's feasibility as a performant, i.e., game engine or real-time application language?

[kccqzy]

In a nutshell, you can create a region and add data to this region and the GC will never look inside it. That is, as long as there is one external reference to any object in this region, the whole region will be kept alive. This is most useful when you know beforehand that you will never deallocate this region of data anyway: it reduces GC latency. Another benefit is that this region can then be serialized to disk efficiently. Deserialization is pretty efficient as it involves as loading the whole thing into memory and fixing up pointers. Reminds me of the Emacs dump[1] though.

[1]: https://lwn.net/Articles/673724/

[shadytrees]

On Ed Yang's repo <https://github.com/ezyang/compact>, which I believe features a version of the Data.Compact module that got merged into base, he gives the example of a spellchecker whose max pauses went from (0.0023,0.0582) to (0.0017,0.0462). In the example the faster version stores the set of dictionary words result you also get disk (de-)serialization, which allows you to amortize the initial cost string parsing.

Unfortunately, I doubt that nondeterministic garbage collection will ever mesh well with high-performance gaming and especially ever with real-time problems. For ordinary systems programming, however, I think it's frequently possible for high-resident-memory applications to build a walled garden for their e.g. in-memory caches or large binary assets.