Как насчет производительности сборщика мусора Haskell для мягких приложений реального времени, таких как игры?

Поскольку я понял, что логика правил игры должна справляться с огромной сложностью, я рассматриваю возможность использования нетипичного языка в игровом поле в качестве скриптового языка игровой логики. Причина в том, что внутриигровой скрипт представляет сложную логику с меньшим количеством кода. Поэтому требуется чрезвычайно хорошо абстрагированный язык.

Но большинство хорошо абстрагированных языков используют GC. И обычно сборщики мусора создают пиковую нагрузку на ЦП. По сути, он откладывает операцию очистки памяти и делает это сразу. Действительно критично для графики в реальном времени, включая игры и графический интерфейс.

AFAIK, Haskell ' s GC немного отличается от других языков, основанных на GC, потому что это неизменяемый атрибут. Сложно представить. Я не смог найти ни одного подробного документа.

Что изменилось? И это освобождает ЦП для длительно работающих программ? (хорошо распределенная нагрузка во времени, для каждого тика может быть вызвана полная команда GC вручную)