Optimize task (V. Yashin)

.gitignore

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

Gemfile

@@ -0,0 +1,11 @@
+# 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'

Gemfile.lock

@@ -0,0 +1,46 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    benchmark-malloc (0.2.0)
+    benchmark-perf (0.6.0)
+    benchmark-trend (0.4.0)
+    coderay (1.1.3)
+    diff-lcs (1.5.1)
+    method_source (1.1.0)
+    minitest (5.23.1)
+    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
+  minitest
+  pry
+  rspec-benchmark
+  ruby-prof
+  ruby-progressbar
+
+BUNDLED WITH
+   2.2.32

case-study.md

@@ -0,0 +1,67 @@
+# Case-study оптимизации
+
+## Актуальная проблема
+В нашем проекте возникла серьёзная проблема.
+
+Необходимо было обработать файл с данными, чуть больше ста мегабайт.
+
+У нас уже была программа на `ruby`, которая умела делать нужную обработку.
+
+Она успешно работала на файлах размером пару мегабайт, но для большого файла она работала слишком долго, и не было понятно, закончит ли она вообще работу за какое-то разумное время.
+
+Я решил исправить эту проблему, оптимизировав эту программу.
+
+## Формирование метрики
+Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: время выполнения программы на файле из 20 000 строк.
+
+## Гарантия корректности работы оптимизированной программы
+Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации.
+
+## Feedback-Loop
+Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за ~1 минуту.
+
+Вот как я построил `feedback_loop`:
+
+Встроил в программу progressbar для возможности визуального контроля за прогрессом выполнения
+Зафиксировал время выполнения исходной программы на файле из 20 000 строк (около 3.3 с)
+Использовал инструменты профилирования для выявления точек роста
+При выявлении точки роста вносил изменения и убеждался в том, что они позитивно влияют на выбранную метрику
+По мере ускорения выполнения программы увеличивал объём тестового файла
+
+## Вникаем в детали системы, чтобы найти главные точки роста
+Для того, чтобы найти "точки роста" для оптимизации я воспользовался ruby-prof и rbspy.
+
+Вот какие проблемы удалось найти и решить
+
+### Находка №1
+
+ruby-prof в режиме flat показал точку роста при формировании списка сессий пользователя с помощью `Array#select`.
+Я решил провести оптимизацию путём замены массива сессий на хэш с ключом в виде id пользователя и значением - списком сессий с этим id.
+Все фрагменты кода, обращающиеся к массиву sessions также переписал с учётом новой специфики и убедился, что тест, поставляемый с программой, не падает.
+Согласно новому отчёту профилировщика, присвоение сессий пользователям перестало быть точкой роста.
+
+### Находка №2
+
+Так как время выполнения программы значительно уменьшилось на выбранном объёме данных, решил его увеличить до 100 000 строк.
+Время выполнения с этим объёмом увеличилось до ~3.5 с.
+ruby-prof в формате CallStack показал точку роста при подсчёте уникальных браузеров методом `Array#all?`.
+Время выполнения уменьшилось до ~2.7 с, подсчёт уникальных браузеров перестал быть точкой роста.
+
+### Находка № 3
+В call tree увидел, что значительное время уходит на парсинг даты.
+Дата и так в нужном формате, поэтому убрал парсинг и заменил `#reverse` на `#reverse!`, время выполнения уменьшилось до ~2.4 с
+
+### Находка № 4
+Call tree показало точку роста при проходе по юзерам (`Array#each`).
+Я оптимизировал этот момент путём переделки массива юзеров в хэш и обработки их в одном цикле с сессиями (по мере нахождения новые сессии добавляются к юзеру по id (ключ хэша))
+От хэша с сессиями при этом избавился из-за избыточности.
+Время выполнения при текущем объеме данных уменьшилось до ~1.1 с.
+
+## Результаты
+В результате проделанной оптимизации наконец удалось обработать файл с данными.
+Удалось улучшить метрику системы с 3.3 секунд до 0.15 секунд и уложиться в заданный бюджет.
+Обработка полного файла (data_large.txt) занимает около 24 секунд.
+
+## Защита от регрессии производительности
+Для защиты от потери достигнутого прогресса при дальнейших изменениях программы я добавил тест на производительность при обработке файла из 20 000 строк и зафиксировал в нём достигнутый результат.
+