Сравнил три парсера по памяти на одном задании

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

Условия одинаковые: 30 соединений, тот же список, тот же диск. Разница вышла заметнее, чем я ждал.

Node меня удивил. Скрипт короткий, лишнего в памяти не держит, память всё равно ползёт вверх весь прогон. Кто копал в эту сторону?

Сразу вопрос по методике: чем мерили и что считали пиком.

Мерил через /usr/bin/time -v, брал строку Maximum resident set size. Сверху раз в минуту смотрел pmap, чтобы понять, растёт ровно или ступеньками.

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

Ступеньки без отката это почти всегда накопление, течь в самом движке тут ни при чём.

Три места, где в Node оно вылезает чаще всего.

Первое: результат копится в массиве и пишется в файл одним куском в конце. Пока прогон идёт, весь разобранный csv лежит в памяти. На 400 тысячах строк по 300 байт это уже больше сотни мегабайт, и сверху накладные расходы на объекты, а они у V8 немаленькие.

Второе: буферы ответов. Если вы собираете тело через body += chunk, каждая склейка порождает новую строку. Сборщик их подберёт, но с задержкой, и пик по памяти вы уже увидели.

Третье: очередь заданий целиком в памяти. Прочитали файл со списком через readFileSync и split, получили массив на 400 тысяч строк. Он живёт до конца прогона, потому что на него ссылается цикл.

У Scrapy память ниже ровно потому, что очередь по умолчанию уезжает на диск, а строки отдаются генератором по одной.

а генератор это что, можно на пальцах

Функция, которая отдаёт строки по одной по запросу, вместо того чтобы вернуть сразу весь список.

const fs = require('fs'), readline = require('readline');
async function* stroki(put) {
  const rl = readline.createInterface({ input: fs.createReadStream(put), crlfDelay: Infinity });
  for await (const s of rl) if (s.trim()) yield s.trim();
}

Файл читается кусками, в памяти висит одна строка плюс буфер потока. Замените readFileSync на это, и ступеньки станут заметно ниже.

Добавлю сбоку про запись. Открывайте поток на вывод один раз и пишите по мере разбора, с оглядкой на drain. Тогда массив с результатами вам вообще не нужен, память перестаёт зависеть от длины списка.

И про машину. Такие замеры на домашней тачке врут: там и своп другой, и сеть неровная. Длинные прогоны я увожу на арендованный сервер, беру приватные серверные адреса для парсинга с безлимитным трафиком и мерю уже там. Цифры получаются повторяемые.

Вот оно. У меня именно readFileSync и split на старте. Переделываю.

Перемерил у себя на похожем задании после правок, оставлю цифры для сравнения.

Разница в шесть раз на ровном месте.

Прошу учесть при чтении темы: пик у A-Parser зависит от того, сколько результатов вы держите в наборе до выгрузки. Поставьте выгрузку каждые десять тысяч строк, и его цифра тоже просядет. Сравнение честное только при одинаковых настройках выгрузки.

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

Закрываю. Итог для тех, кто найдёт поиском: память ела не библиотека, ела моя привычка держать весь список рядом.