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>

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

Линейка инструментов Chrome Dev Tools

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

Источник

3 ответа

введите описание изображения здесь

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

<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 почти не изменяются, поэтому, вероятно, это связано с отладкой Chrome (см. Подробности в связанном отчете об ошибках Chrome выше). Тем не менее, я заметил улучшение в моей собственной игре при развертывании RAF, как это, и, черт возьми, мне нужно иметь возможность отлаживать его без искусственных сборщиков мусора, что не произойдет на машинах обычных пользователей.

Источник

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

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

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

Источник

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

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

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

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

Источник
Другие вопросы по тегам