[potashin] optimization by suslovnikita · Pull Request #141 · hardcode-dev/rails-optimization-task1

suslovnikita · 2024-04-28T23:49:58Z

No description provided.

suslovnikita · 2024-04-29T13:32:24Z

case-study.md

+- исправленная проблема перестала быть главной точкой роста.
+
+### Находка №6
+- `ruby-prof` в режиме `CallStack` показывает, что точкой роста является `7.20% (15.82%) Array#include? [846230 calls, 846230 total]`


вот так чтобы не натыкаться на грабли собственной оптимизации, имеет смысл чуть расширять контекст кода, который нужно оптимизировать (я имею в виду находку №4)? т.е. условно не all?, а все формирование уникальных элементов.

хм, я бы сказал можно так и так

с одной стороны в 4м шаге ты убрал на тот момент топовую проблему из топа, и перешёл к следующей; тут она опять пробилась в топ - опять поправил - по идее это весьма логично

с другой стороны тут случай, что можно заметить, что есть возможность использовать более подходящую структуру данных/алгоритм, по идее можно эту сразу было сделать (но тут есть риск что-то поломать иногда; но тесты должны подстраховать; но это в случае если они есть)

suslovnikita · 2024-04-29T13:33:34Z

case-study.md

+### Находка №7
+- `ruby-prof` в режиме `CallGrind` показывает, что точкой роста является `Object::collect_stats_from_users`-> `Array::map`->`String::upcase`
+- поскольку используется только `upcase` версия браузера, при парсинге сессия сразу записываем `upcase` версию. Поскольку не так много видов браузеров относительно общего количества сессий, используем мемоизацию.
+- время выполнения программы для 1кк входных данных сократилось с 6.9 до с 6.4c


тут интересно, что несмотря на то, что это главная точка роста, время сократилось не так сильно, как на следующем этапе

такое возможно из-за GC;

когда мы профлируем CPU, есть такая тонкость; возможно какая-то строчка не тормозит сама по себе, но создаёт много лишних объектов, которые потом наступит время убирать

поэтому если хочешь ускорить время работы максимально, то имеет смысл с обоих сторон смотреть - и по CPU, и по памяти (хотя на первый взгляд память это не про скорость; особенно в этом плане наверно важно кол-во аллоцированных объектов; если их слишком много создаётся и удаляется, то будет тормозить)

spajic

Привет! Всё топчик, постарался развёрнуто покомментить. Вероятно ты это всё и сам знаешь, но просто в качестве беседы тогда ✅

spajic · 2024-04-30T21:51:55Z

.gitignore

@@ -0,0 +1,10 @@
+result.json
+data*.txt


respect за gitignore

надо бы добавить в репу, а то иногда прилетают PR'ы на 200к строк кода

spajic · 2024-04-30T21:55:31Z

case-study.md

+Я решил исправить эту проблему, оптимизировав эту программу.
+
+## Формирование метрики
+Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: время выполнения программы для части данных (сначала 50к, потом 100к).


++

тут получается немного tricky

у нас есть некоторая целевая метрика, но мы не можем ей пользоваться из-за того что даже не можем дождаться

В качестве выхода мы можем взять какие-то промежуточные метрики; например, чтобы оценить одно изменение, или парочку.

Плюс если мы понимаем асимптотику (например если она линейная), то мы можем и довольно-таки обоснованно прикинуть, что для примера 1/100 данных должна обрабатываться за 300 мс, и тогда вероятно общее время выполнения будет около 30с

Хорошо подбирать объём данных так, чтобы программа успевала покрутиться пару секунд. Если она завершается слишком быстро (“не успевает поработать”) могут возникнуть какие-то перекосы (например, на полном объёме основная часть времени тратится в основном цикле, а если данных мало - то большая часть уходит на инициализацию и финализацию, например на чтение из файла и запись потом в файл)

И плюс когда время уже на миллисекунды - больше влияние погрешностей.

spajic · 2024-04-30T21:56:14Z

case-study.md

+Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации.
+
+## Feedback-Loop
+Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за *время, которое у вас получилось*


*это был плейсхолдер*

spajic · 2024-04-30T21:56:55Z

case-study.md

+- rbspy показал `83.55    83.55  block (2 levels) in work - task-1.rb:101`: вызов `sessions.filter {}` на каждой итерации по `users.each`;
+- перед `users.each` сгруппировал `sessions_by_user = sessions.group_by { |session| session['user_id'] }`, в `each` использовал как `sessions_by_user[user['id']] || []`
+- время выполнения программы для 100к входных данных сократилось с 115с до 4с
+- исправленная проблема перестала быть главной точкой роста, rbspy показал, что теперь это `98.49   100.00  block in work - task-1.rb:56`


и самое главное асимптотика уже стала из квадратичной - линейной

spajic · 2024-04-30T21:57:56Z

case-study.md

+- исправленная проблема перестала быть главной точкой роста, rbspy показал, что теперь это `98.49   100.00  block in work - task-1.rb:56`
+
+### Находка №2
+- stackprof cli показал `7126  (99.4%)          11   (0.2%)     Array#each`, он вызывается несколько раз, наибольшее `6504  (   91.3%)  Object#work]`. Поскольку rbspy указывал на `task-1.rb:56`, что является `end` `each` блока, пробую вынести этот`each` в отдельный метод `parse_file`и подтвердить гипотезу, которая и подтверждается: `5765  (99.8%)        5525  (95.7%)     Object#parse_file`. Теперь нужно разобраться, какая именно операция в этом блоке `each` требует оптимизации, `stackprof stackprof.dump --method Object#parse_file` показывает, что это заполнение массива сессий: `5261   (93.2%) /  5133  (90.9%)  |    52  |     sessions = sessions + [parse_session(line)] if cols[0] == 'session'`.


респект, что уточнил чуть глубже куда конкретно время уходит

spajic · 2024-04-30T22:02:33Z

case-study.md

+- исправленная проблема перестала быть главной точкой роста.
+
+### Находка №6
+- `ruby-prof` в режиме `CallStack` показывает, что точкой роста является `7.20% (15.82%) Array#include? [846230 calls, 846230 total]`


хм, я бы сказал можно так и так

с одной стороны в 4м шаге ты убрал на тот момент топовую проблему из топа, и перешёл к следующей; тут она опять пробилась в топ - опять поправил - по идее это весьма логично

с другой стороны тут случай, что можно заметить, что есть возможность использовать более подходящую структуру данных/алгоритм, по идее можно эту сразу было сделать (но тут есть риск что-то поломать иногда; но тесты должны подстраховать; но это в случае если они есть)

spajic · 2024-04-30T22:06:27Z

case-study.md

+### Находка №7
+- `ruby-prof` в режиме `CallGrind` показывает, что точкой роста является `Object::collect_stats_from_users`-> `Array::map`->`String::upcase`
+- поскольку используется только `upcase` версия браузера, при парсинге сессия сразу записываем `upcase` версию. Поскольку не так много видов браузеров относительно общего количества сессий, используем мемоизацию.
+- время выполнения программы для 1кк входных данных сократилось с 6.9 до с 6.4c


такое возможно из-за GC;

когда мы профлируем CPU, есть такая тонкость; возможно какая-то строчка не тормозит сама по себе, но создаёт много лишних объектов, которые потом наступит время убирать

поэтому если хочешь ускорить время работы максимально, то имеет смысл с обоих сторон смотреть - и по CPU, и по памяти (хотя на первый взгляд память это не про скорость; особенно в этом плане наверно важно кол-во аллоцированных объектов; если их слишком много создаётся и удаляется, то будет тормозить)

spajic · 2024-04-30T22:07:02Z

case-study.md

+
+## Результаты
+В результате проделанной оптимизации наконец удалось обработать файл с данными.
+Удалось улучшить метрику системы на 100к с 115с до 5с секунд и уложиться в заданный бюджет. Для полного файла время выполнение стало 24с.


spajic · 2024-04-30T22:07:13Z

case-study.md

+Удалось улучшить метрику системы на 100к с 115с до 5с секунд и уложиться в заданный бюджет. Для полного файла время выполнение стало 24с.
+
+## Защита от регрессии производительности
+Для защиты от потери достигнутого прогресса при дальнейших изменениях программы добавил два теста: прогон на 100к данных до 5 секунд, проверка на линейную асимптотику на основе данных от 1000 до 100000 записей.


chore: perform optimizations

d118968

suslovnikita marked this pull request as draft April 28, 2024 23:51

suslovnikita added 4 commits April 29, 2024 13:23

chore: add profiler files

cdd62a0

chore: add 3 more steps

6f67219

chore: add progresssbar

bdd8a43

chore: adjust specs

e89db7b

suslovnikita marked this pull request as ready for review April 29, 2024 13:17

suslovnikita commented Apr 29, 2024

View reviewed changes

suslovnikita force-pushed the feature/potashin-optimization branch 2 times, most recently from 8cb83b6 to 41177e6 Compare April 29, 2024 13:36

fix: typos

7dbada5

suslovnikita force-pushed the feature/potashin-optimization branch from 41177e6 to 7dbada5 Compare April 29, 2024 13:37

spajic approved these changes Apr 30, 2024

View reviewed changes

fix: case study

f6610b9

suslovnikita force-pushed the feature/potashin-optimization branch from d36a77e to f6610b9 Compare May 1, 2024 08:15

		@@ -0,0 +1,10 @@
		result.json
		data*.txt

Conversation

suslovnikita commented Apr 28, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spajic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants