Неужели Эликсирский мусорный коллектор страдает от остановки мировой паузы? [Дубликат]

Ваш код getElementById() работает, поскольку идентификаторы должны быть уникальными, и поэтому функция всегда возвращает ровно один элемент (или null, если ни один не найден).

Однако getElementsByClassName() , querySelectorAll() и другие методы getElementsBy* возвращают массивный набор элементов. Итерации над ним, как и с реальным массивом:

var elems = document.getElementsByClassName('myElement');
for(var i = 0; i < elems.length; i++) {
    elems[i].style.size = '100px';
}

Если вы предпочитаете что-то более короткое, рассмотрите использование jQuery :

$('.myElement').css('size', '100px');

21
задан user1002288 19 April 2012 в 06:00
поделиться

4 ответа

Справочный документ для алгоритма: One Pass Real-Time Generation Mark-Sweep Garbage Collection (1995) Джо Армстронга и Роберта Вирдинга в 1995 году (в CiteSeerX)

14
ответ дан jj1bdx 22 August 2018 в 11:26
поделиться

Чтобы классифицировать вещи, давайте определим макет памяти, а затем поговорим о том, как работает GC.

Макет памяти

В Erlang каждый поток исполнения называется процессом. Каждый процесс имеет свою собственную память, а макет памяти состоит из трех частей: блок управления процессом, стек и куча.

  • PCB: процесс Контрольный блок содержит информацию, такую ​​как идентификатор процесса (PID), текущее состояние (работа, ожидание), его зарегистрированное имя и т. Д.
  • Stack: это растущая область памяти, которая поддерживает входящие и исходящие параметры , возвращать адреса, локальные переменные и временные пробелы для оценки выражений.
  • Куча: это растущая область памяти, которая содержит сообщения почтового ящика процесса и составные термины. Двоичные термины, размер которых превышает 64 байта, НЕ хранятся в частной куче процесса. Они хранятся в большой Shared Heap, доступной для всех процессов.

Сбор мусора

В настоящее время Erlang использует коллекцию мусора Generational, которая работает внутри каждого Erlang обрабатывать частную кучу независимо, а также собирать сборку ссылок Counting для глобальной общей кучи.

  • Private Heap GC: Это поколение, поэтому делит кучу на два сегмента: молодое и старое поколение. Также есть две стратегии для сбора; Генерация (Малая) и Fullsweep (Major). Генерация GC просто собирает молодую кучу, но fullsweep собирает как молодую, так и старую кучу.
  • Общая куча GC: Это подсчет ссылок. Каждый объект в общей куче (Refc) имеет счетчик ссылок на него, хранящийся другими объектами (ProcBin), которые хранятся внутри частной кучи процессов Erlang. Если контрольный счетчик объекта достигает нуля, объект становится недоступным и будет уничтожен.

Чтобы получить более подробную информацию и рекомендации по производительности, просто взгляните на мою статью, которая является источником ответ: Подробности коллекции мусора Эрланг и почему это имеет значение

13
ответ дан Hamidreza Soleimani 22 August 2018 в 11:26
поделиться

У Erlang есть несколько свойств, которые делают GC очень простым.

1 - Каждая переменная неизменна, поэтому переменная никогда не может указывать на значение, которое было создано после нее.

2 - Значения копируются между процессами Erlang, поэтому память, упоминаемая в процессе, почти всегда полностью изолирована.

Оба эти (особенно последние) значительно ограничивают количество кучи, которое GC имеет сканирование во время сбора.

Erlang использует копию GC. Во время GC процесс останавливается, а живые указатели копируются из пространства из пространства в космос. Я забываю точные проценты, но куча будет увеличена, если во время сбора можно будет собрать только 25% кучи, и она будет уменьшена, если можно собрать 75% кучи процесса. Коллекция запускается, когда куча процесса заполняется.

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

. Одним из интересных следствий этого является то, что для общего объекта размер общего объекта не вносит вклад в расчетный размер кучи процесса, только размер ссылки. Это означает, что если у вас много больших общих объектов, у вашей виртуальной машины может закончиться память до запуска GC.

Большинство, если это взято из разговора, которое Jesper Wilhelmsson дал в EUC2012.

12
ответ дан orbitz 22 August 2018 в 11:26
поделиться

Я не знаю вашего фона, но кроме бумаги, уже упомянутой jj1bdx, вы также можете дать тезис Джеспера Вильгельмсона .

Кстати, если вы хотите контролировать использование памяти в Erlang, чтобы сравнить его с, например, C ++ вы можете проверить:

Надеюсь, это поможет!

2
ответ дан Vincenzo Maggio 22 August 2018 в 11:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: