init

Author: aushev-dev

Gemfile

@@ -0,0 +1,7 @@
+source "https://rubygems.org"
+gem "ruby-prof"
+# gem "rspec-benchmark"
+gem "ruby-progressbar"
+gem "minitest"
+gem "memory_profiler"
+gem "stackprof"

Gemfile.lock

@@ -0,0 +1,22 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    memory_profiler (1.1.0)
+    minitest (5.25.4)
+    ruby-prof (1.6.3)
+    ruby-progressbar (1.13.0)
+    stackprof (0.2.27)
+
+PLATFORMS
+  arm64-darwin-23
+  ruby
+
+DEPENDENCIES
+  memory_profiler
+  minitest
+  ruby-prof
+  ruby-progressbar
+  stackprof
+
+BUNDLED WITH
+   2.4.10

app.rb

@@ -0,0 +1,8 @@
+require_relative 'task-2'
+require 'benchmark'
+require 'memory_profiler'
+
+report = MemoryProfiler.report do
+  work(file_name = '50000.txt', disable_gc =false)
+end
+report.pretty_print(scale_bytes: true)

case-study-template.md

@@ -0,0 +1,127 @@
+# Case-study оптимизации
+
+## Актуальная проблема
+В нашем проекте возникла серьёзная проблема.
+
+Необходимо было обработать файл с данными, чуть больше ста мегабайт.
+
+У нас уже была программа на `ruby`, которая умела делать нужную обработку.
+
+Она успешно работала на файлах размером пару мегабайт, но для большого файла она работала слишком долго, и не было понятно, закончит ли она вообще работу за какое-то разумное время.
+
+Я решил исправить эту проблему, оптимизировав эту программу.
+
+## Формирование метрики
+Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику:
+* время выполнения программы.
+* потребление памяти
+
+## Гарантия корректности работы оптимизированной программы
+Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации.
+
+## Feedback-Loop
+Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за 1-2 минуты
+
+Вот как я построил `feedback_loop`: создал файлы с различным количеством строк, чтобы программа могла выполняться за 10–20 секунд.
+После каждого изменения я запускал программу на файлах с разным количеством строк и смотрел на результаты отчетов.
+
+## Вникаем в детали системы, чтобы найти главные точки роста
+Для того, чтобы найти "точки роста" для оптимизации я воспользовался:
+- gem memory_profiler
+- gem ruby-prof и отчеты callstack & qcachegrind
+- gem stackprof + CLI и Speedscope
+- второй thread для мониторинга памяти
+
+Вот какие проблемы удалось найти и решить:
+
+### №1 Уменьшение создания временных массивов при добавлении элементов 
+```
+    sessions = sessions + [parse_session(line)] if cols[0] == 'session'
+```
+- memory_profiler
+- Вместо оператора + было применено использование метода <<, который добавляет элемент в существующий массив без создания нового объекта.
+- До оптимизации программе аллоцировалось 460MB памяти на файле размером 10_000 строк, после оптимизации уже 155MB
+- данная проблема перестала быть главной точкой роста
+
+### №2 Избыточное создание массивов при фильтрации сессий для каждого пользователя
+```
+    user_sessions = sessions.select { |session| session['user_id'] == user['id'] }
+```
+- memory_profiler
+- Проблема возникает в строке user_sessions = sessions.select { |session| session['user_id'] == user['id'] }, где для каждого пользователя создается новый массив отфильтрованных сессий. Это приводит к повторным обходам большого массива sessions, и для каждого пользователя в памяти хранятся временные массивы, что заметно увеличивает использование памяти.
+- Чтобы избежать повторного обхода массива для каждого пользователя и избыточного создания временных массивов, все сессии были предварительно сгруппированы по user_id с использованием метода group_by. После этого для каждого пользователя мы просто обращаемся к уже сгруппированным данным через хеш (sessions_by_user[user['id']]).
+- До оптимизации программе аллоцировалось 155MB памяти на файле размером 10_000 строк, после оптимизации уже 42MB.
+- данная проблема перестала быть главной точкой роста
+
+### №3  Уменьшение создания временных массивов при добавлении элементов
+```
+    users = users + [parse_user(line)] if cols[0] == 'user'
+```
+- memory_profiler
+- Вместо оператора + было применено использование метода <<, который добавляет элемент в существующий массив без создания нового объекта.
+- До оптимизации программе аллоцировалось 636MB памяти на файле размером 50_000 строк, после оптимизации уже 400MB
+- данная проблема перестала быть главной точкой роста
+
+### №4 Уменьшение создания временных массивов при добавлении элементов
+```
+    users_objects = users_objects + [user_object]
+```
+- memory_profiler
+- Вместо оператора + было применено использование метода <<, который добавляет элемент в существующий массив без создания нового объекта.
+- До оптимизации программе аллоцировалось 400MB памяти на файле размером 50_000 строк, после оптимизации уже 160MB
+- Данная проблема перестала быть главной точкой роста
+
+### №5 Излишний парсинг дат и преобразование в формат iso8601
+```
+     { 'dates' => user.sessions.map{|s| s['date']}.map {|d| Date.parse(d)}.sort.reverse.map { |d| d.iso8601 } }
+```
+- qcachegrind из ruby-prof
+- Так как мы уже имеем данные в нужном формате, то было принято решение не тратить время на преобразование даты в формат iso8601
+- До оптимизации программе аллоцировалось 160MB памяти на файле размером 50_000 строк, после оптимизации уже 120MB
+- Данная проблема перестала быть главной точкой роста
+
+### №6 Избыточное создание временных массивов
+```
+cols = line.split(',')
+```
+- memory_profiler
+- Вместо разделения строки на части с помощью split и проверки первого элемента, я решил использовать метод start_with?
+- До оптимизации программе аллоцировалось 120MB памяти на файле размером 50_000 строк, после оптимизации уже 100MB.
+- Данная проблема перестала быть главной точкой роста
+
+### №7 Избыточное потребление памяти из-за создания новых хэшей при merge
+```
+    report['usersStats'][user_key] = report['usersStats'][user_key].merge(block.call(user))
+```
+- memory_profiler
+- Был использован метод merge! вместо merge, который изменяет оригинальный хэш на месте, избегая лишнего копирования данных
+- До оптимизации программе аллоцировалось 200MB памяти на файле размером 100_000 строк, после оптимизации уже 184MB.
+- Данная проблема перестала быть главной точкой роста
+
+### №X
+```
+    report['usersStats'][user_key] = report['usersStats'][user_key].merge(block.call(user))
+```
+- какой отчёт показал главную точку роста
+- как вы решили её оптимизировать
+- как изменилась метрика
+- как изменился отчёт профилировщика
+
+## Результаты
+В результате проделанной оптимизации наконец удалось обработать файл с данными.
+Удалось улучшить метрику системы с *того, что у вас было в начале, до того, что получилось в конце* и уложиться в заданный бюджет.
+
+*Какими ещё результами можете поделиться*
+
+## Защита от регрессии производительности
+Для защиты от потери достигнутого прогресса при дальнейших изменениях программы *о performance-тестах, которые вы написали*
+
+
+
+подготовил файлы 10_000 и 100_000 строк для тестирования
+```
+head -n N data_large.txt > dataN.txt # create smaller file from larger (take N first lines)
+```
+
+
+

case-study.md

@@ -39,20 +39,25 @@ def collect_stats_from_users(report, users_objects, &block)
   users_objects.each do |user|
     user_key = "#{user.attributes['first_name']}" + ' ' + "#{user.attributes['last_name']}"
     report['usersStats'][user_key] ||= {}
-    report['usersStats'][user_key] = report['usersStats'][user_key].merge(block.call(user))
+    report['usersStats'][user_key] = report['usersStats'][user_key].merge!(block.call(user))
   end
 end
 
-def work
-  file_lines = File.read('data.txt').split("\n")
+def work(file_path = 'data.txt', disable_gc = false)
+  GC.disable if disable_gc
+
+  file_lines = File.read(file_path).split("\n")
 
   users = []
   sessions = []
 
   file_lines.each do |line|
-    cols = line.split(',')
-    users = users + [parse_user(line)] if cols[0] == 'user'
-    sessions = sessions + [parse_session(line)] if cols[0] == 'session'
+    case
+    when line.start_with?('user,')
+      users << parse_user(line)
+    when line.start_with?('session,')
+      sessions << parse_session(line)
+    end
   end
 
   # Отчёт в json
@@ -96,11 +101,13 @@ def work
   # Статистика по пользователям
   users_objects = []
 
+  sessions_by_user = sessions.group_by { |session| session['user_id'] }
+
   users.each do |user|
     attributes = user
-    user_sessions = sessions.select { |session| session['user_id'] == user['id'] }
+    user_sessions = sessions_by_user[user['id']] || []
     user_object = User.new(attributes: attributes, sessions: user_sessions)
-    users_objects = users_objects + [user_object]
+    users_objects << user_object
   end
 
   report['usersStats'] = {}
@@ -137,7 +144,7 @@ def work
 
   # Даты сессий через запятую в обратном порядке в формате iso8601
   collect_stats_from_users(report, users_objects) do |user|
-    { 'dates' => user.sessions.map{|s| s['date']}.map {|d| Date.parse(d)}.sort.reverse.map { |d| d.iso8601 } }
+    { 'dates' => user.sessions.map{|s| s['date']}.sort.reverse }
   end
 
   File.write('result.json', "#{report.to_json}\n")