Для работы скрипта требуется Ruby 2.4+

В этом задании нужно оптимизировать программу из первого задания, но теперь с фокусом на оптимизацию памяти.

Программа не должна потреблять больше 70Мб памяти при обработке файла data_large в течение всей своей работы.

Из бюджета очевидно, что мы не можем ни считывать файл в память целиком, ни накапливать в памяти данные по пользователям.

Значит, программу нужно переосмыслить и написать в "потоковом" стиле - когда мы читаем исходный файл строку за строкой и сразу же на ходу пишем файл с результатами.

На этот раз для прохождения теста достаточно, чтобы результат совпадал с эталоном как json-объект, а не строка. То есть порядок полей в объекте не важен.

Можем считать, что все сессии юзера всегда идут одним непрерывным куском. Нет такого, что сначала идёт часть сессий юзера, потом сессии другого юзера, и потом снова сессии первого.

В этот раз переработка потребуется кардинальная, так что нужно сделать два этапа

• перевести программу на потоковый подход так чтобы она прошла тесты
• профилировать получившуюся программу рассмотренными инструментами и оптимизировать память ещё сильнее, сделать две-три итерации по фреймворку оптимизации и написать case-study
• когда закончите, сделайте замер времени работы программы; получилось ли быстрее чем при оптимизации по процессору в первом задании?

В фидбек-лупе можно получать кол-во памяти в конце выполнения программы:

puts "MEMORY USAGE: %d MB" % (`ps -o rss= -p #{Process.pid}`.to_i / 1024)"

После успешной оптимизации дополнительно нужно профилировать программу с помощью valgrind massif visualizer и проверить, что память укладывается в бюджет не только в конце работы программы, но и в течение вообще всего времени работы.

Для сдачи задания нужно форкнуть этот проект, сделать PR в него и прислать ссылку для проверки.

В PR

• должны быть внесены оптимизации в task-2.rb;
• должен быть файл case-study.md с описанием проделанной оптимизации;
• в описании должен быть скриншот из valgrind massif visualizer, на котором видно, что программа укладывается в бюджет на протяжении всего времени исполнения;
• в описание PR добавьте чеклист и отметьте, что из него сделали; для получения максимальной пользы надо отметить всё.

• Построить и проанализировать отчёт гемом memory_profiler
• Построить и проанализировать отчёт ruby-prof в режиме Flat;
• Построить и проанализировать отчёт ruby-prof в режиме Graph;
• Построить и проанализировать отчёт ruby-prof в режиме CallStack;
• Построить и проанализировать отчёт ruby-prof в режиме CallTree c визуализацией в QCachegrind;
• Построить и проанализировать текстовый отчёт stackprof;
• Построить и проанализировать отчёт flamegraph с помощью stackprof и визуализировать его в speedscope.app;
• Построить график потребления памяти в valgrind massif visualier и включить скриншот в описание вашего PR;
• Написать тест, на то что программа укладывается в бюджет по памяти

Не нужно включать в PR выводы всех этих отчётов, просто используйте каждый хотя бы по разу в вашем Case-study.

Каждый шаг оптимизации в case-study должен содержать четыре составляющих:

• какой отчёт показал главную точку роста
• как вы решили её оптимизировать
• как изменилась метрика
• как изменился отчёт профилировщика

• Не отключайте GC при вычислении метрики
• Отключайте профилировщик при вычислении метрики
• Используйте все описанные инструменты и отчёты хотя бы по разу – научитесь с ними работать!
• Вкладывайтесь в удобство разработки и скорость фидбек-лупа!