Optimize memory usage

.gitignore

@@ -0,0 +1,7 @@
+/.bundle
+/.idea
+.DS_Store
+result.json
+report.json
+report.html
+data_large.txt

Gemfile

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+source "https://rubygems.org"
+
+git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }
+
+gem 'pry'
+gem 'minitest'
+gem 'rspec-benchmark'
+gem 'ruby-progressbar'
+gem 'ruby-prof'
+gem 'memory_profiler'
+gem 'oj'

Gemfile.lock

@@ -0,0 +1,52 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    benchmark-malloc (0.2.0)
+    benchmark-perf (0.6.0)
+    benchmark-trend (0.4.0)
+    bigdecimal (3.1.8)
+    coderay (1.1.3)
+    diff-lcs (1.5.1)
+    memory_profiler (1.0.2)
+    method_source (1.1.0)
+    minitest (5.23.1)
+    oj (3.16.4)
+      bigdecimal (>= 3.0)
+    pry (0.14.2)
+      coderay (~> 1.1)
+      method_source (~> 1.0)
+    rspec (3.13.0)
+      rspec-core (~> 3.13.0)
+      rspec-expectations (~> 3.13.0)
+      rspec-mocks (~> 3.13.0)
+    rspec-benchmark (0.6.0)
+      benchmark-malloc (~> 0.2)
+      benchmark-perf (~> 0.6)
+      benchmark-trend (~> 0.4)
+      rspec (>= 3.0)
+    rspec-core (3.13.0)
+      rspec-support (~> 3.13.0)
+    rspec-expectations (3.13.0)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.13.0)
+    rspec-mocks (3.13.1)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.13.0)
+    rspec-support (3.13.1)
+    ruby-prof (1.7.0)
+    ruby-progressbar (1.13.0)
+
+PLATFORMS
+  arm64-darwin-21
+
+DEPENDENCIES
+  memory_profiler
+  minitest
+  oj
+  pry
+  rspec-benchmark
+  ruby-prof
+  ruby-progressbar
+
+BUNDLED WITH
+   2.2.32

case-study.md

@@ -0,0 +1,56 @@
+# Case-study оптимизации
+
+## Актуальная проблема
+В нашем проекте возникла серьёзная проблема.
+
+Необходимо было обработать файл с данными, чуть больше ста мегабайт.
+
+У нас уже была программа на `ruby`, которая умела делать нужную обработку.
+
+Она успешно работала на файлах размером пару мегабайт, но для большого файла она работала слишком долго, и не было понятно, закончит ли она вообще работу за какое-то разумное время.
+
+Я решил исправить эту проблему, оптимизировав эту программу.
+
+## Формирование метрики
+Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: количество потребляемой памяти.
+
+## Гарантия корректности работы оптимизированной программы
+Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации.
+
+## Feedback-Loop
+Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за 1 минуту.
+
+Вот как я построил `feedback_loop`:
+- Запуск программы с профилировщиком
+- Определение точки роста
+- Внесение изменений
+- Запуск программы для определения влияния изменений на метрику
+
+## Вникаем в детали системы, чтобы найти главные точки роста
+Для того, чтобы найти "точки роста" для оптимизации я воспользовался memory_profiler и ruby-prof.
+
+Вот какие проблемы удалось найти и решить
+
+### Ваша находка №1
+
+Я взял за основу проведенную в первом задании оптимизацию, поэтому мог сразу использовать полный файл data_large для тестирования потребления памяти.
+Исходно программа потребляла 3888 мегабайт.
+
+memory-profiler показал высокое использование памяти при чтении всего файла.
+Я переделал чтение файла на потоковое (`File.foreach`), это снизило потребление до 3300 Мб.
+
+### Ваша находка №2
+memory-profiler показал высокое использование памяти при мемоизации данных о пользователях и сессиях
+Я переделал обработку строк на потоковый режим (пишем сразу в файл, когда собрали всю информацию по юзеру). Использовал гем oj (инструмент stream writer).
+Потребление памяти снизилось до 32 Мб.
+
+## Результаты
+В результате проделанной оптимизации наконец удалось обработать файл с данными.
+Удалось улучшить метрику системы с 3888 Мб до 32 Мб и уложиться в заданный бюджет.
+Возникли проблемы с развертыванием проекта в докере под M1 (не собирались нативные расширения), поэтому valgrind massif visualier воспользоваться не удалось.
+Чтобы это частично компенсировать, я добавил периодический вывод в консоль потребляемой памяти, и в ходе обработки файла видно, что она не выходит за допустимые пределы.
+
+Скорость выполнения не ухудшилась в сравнении с оптимизированным первым заданием.
+
+## Защита от регрессии производительности
+Для защиты от потери достигнутого прогресса при дальнейших изменениях программы я добавил тест RSpec на потребляемую память.