Ответ 1
блеск - вот преступник.
Во-первых, немного информации о сборщике мусора GHC. GHC использует (по умолчанию) коллективный сборщик мусора. Это означает, что куча состоит из нескольких областей памяти, называемых поколениями. Объекты выделяются в самое младшее поколение. Когда поколение заполняется, оно сканируется для живых объектов, а живые объекты копируются в следующее поколение, а затем сканируемое поколение помечено как пустое. Когда старое поколение становится полным, живые объекты вместо этого копируются в новую версию самого старого поколения.
Важным фактом, чтобы убрать это, является то, что GC только когда-либо рассматривает живые объекты. Мертвые объекты никогда не касаются. Это здорово, когда вы собираете поколения, которые в основном являются мусором, как это часто бывает у самого молодого поколения. Это не хорошо, если долговечные данные подвергаются много GC, поскольку они будут скопированы повторно. (Он также может быть несовместимым с теми, которые используются для управления памятью malloc/free-style, где выделение и освобождение являются довольно дорогими, но оставляя объекты, выделенные в течение длительного времени, не имеют прямых затрат.)
Теперь "гипотеза поколений" состоит в том, что большинство объектов либо недолговечны, либо долгоживут. Долгоживущие объекты быстро окажутся в старейшем поколении, так как они живы в каждой коллекции. Между тем, большинство короткоживущих объектов, которые выделяются, никогда не выживут в младшем поколении; только те, которые оживают, когда они будут собраны, будут продвигаться к следующему поколению. Точно так же большинство из тех короткоживущих объектов, которые получают повышение, не выживут в третьем поколении. В результате, самое старое поколение, в котором хранятся долгоживущие объекты, должно заполняться очень медленно, и его дорогие коллекции, которые должны копировать все долгоживущие объекты, должны встречаться редко.
Теперь все это действительно верно в вашей программе, за исключением одной проблемы:
let displayFun backendRef = do
-- extract the current time from the state
timeS <- animateSR `getsIORef` AN.stateAnimateTime
-- call the user action to get the animation frame
picture <- frameOp (double2Float timeS)
renderS <- readIORef renderSR
portS <- viewStateViewPort <$> readIORef viewSR
windowSize <- getWindowDimensions backendRef
-- render the frame
displayPicture
windowSize
backColor
renderS
(viewPortScale portS)
(applyViewPortToPicture portS picture)
-- perform GC every frame to try and avoid long pauses
performGC
gloss сообщает GC собирать самое старое поколение в каждом кадре!
Это может быть хорошей идеей, если ожидается, что эти коллекции потребуют меньше времени, чем задержка между кадрами, но это явно не очень хорошая идея для вашей программы. Если вы удалите этот вызов performGC из блеска, ваша программа будет работать довольно быстро. Предположительно, если вы позволите ему работать достаточно долго, то старейшее поколение в конечном итоге заполнится, и вы получите задержку в несколько десятых секунды, поскольку GC скопирует все ваши долговечные данные, но это намного лучше, чем оплата этой стоимости каждый кадр.
Все, что сказано, есть билет # 9052 о добавлении стабильного поколения, которое также прекрасно подойдет вашим потребностям. См. Более подробную информацию.