RequestAnimationFrame сбор мусора

Я профилирую следующее использование памяти кода с помощью временной шкалы в Chrome Dev Tools v27.

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv='content-type' content='text/html; charset=UTF-8' />
  <title>RAF</title>
</head>
  <body>
    <script type='text/javascript' charset='utf-8'>
      var frame = function() {
        window.webkitRequestAnimationFrame(frame);
      };
      window.webkitRequestAnimationFrame(frame);
    </script>
  </body>
</html>

Обратите внимание, что это просто. Но в конце концов я вижу, что появляется образец зуба, который указывает, что сборщик мусора восстанавливает память.

По умолчанию raf создает объекты мусора? Есть ли способ избежать этого? спасибо.

Ответы

Ответ 1

Я думаю, что у Chrome может быть проблема...

аналогичная ошибка уже сообщается здесь:

https://code.google.com/p/chromium/issues/detail?id=120186

Ответ 2

Я выяснил следующее: Если вы измените функцию RAF на две функции "пинг-понга", вы получите гораздо меньше мусора. Вы не можете избежать первого начального "большого GC", но после этого вы видите только небольшие GC размером около 50kb вместо 700kb-1mb GC. Код будет выглядеть так:

<script type='text/javascript' charset='utf-8'>
  window.frameA = function() {
    window.webkitRequestAnimationFrame(window.frameB);
  };
  window.frameB = function() {
    window.webkitRequestAnimationFrame(window.frameA);
  };
  window.webkitRequestAnimationFrame(window.frameA);
</script>

Я думаю, это лучшее, что вы можете сделать в Chrome. Я заметил, что в FF интервалы или память gc практически не меняются, поэтому, вероятно, это связано с хром-отладочной информацией (подробнее см. Отчет об ошибке хрома, приведенный выше). Тем не менее, я заметил улучшение в своей собственной игре при развертывании RAF, как это, - и, черт возьми, мне нужно иметь возможность отлаживать его без искусственных GC, которые не будут выполняться на обычных компьютерах пользователей.

Ответ 3

Он выглядит как цикл сохранения. Кадр вызывает себя, поэтому удерживает счетчик и не освобождается. Также в любое время, когда вы контролируете текущий код с профилем, временной шкалой или кучками кучи, будут какие-то побочные эффекты.

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

Самые большие проблемы с памятью/процессором: сетевые вызовы, распаковка PNG/JPG, создание и уничтожение элементов DOM, обработка/анализ данных в нерабочем потоке, плохое использование текстур графического процессора и распределение большого количества данных для создания GC чтобы занять много времени для сбора данных.

Мне удалось оптимизировать список прокрутки с 1 000 000 элементов для работы на 120FPS на хром (https://github.com/puppybits/BackboneJS-PerfView). Инструменты производительности должны помочь вам найти самые большие проблемы, которые может видеть пользователь, и вам не нужно беспокоиться о мелочах.