Task 1 #153
Task 1 #153
Conversation
| @@ -0,0 +1,150 @@ | |||
| # Case-study оптимизации | |||
|
|
||
| Она успешно работала на файлах размером пару мегабайт, но для большого файла она работала слишком долго, и не было понятно, закончит ли она вообще работу за какое-то разумное время. | ||
|
|
||
| Я решил исправить эту проблему, оптимизировав эту программу. |
| ## Формирование метрики | ||
| Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: | ||
| - время выполнения должно быть линейным | ||
| - в случае линейности 1_000_000 должен работать не больше 9 секунд |
There was a problem hiding this comment.
это намного продуманнее того что обычно пишут, но не совсем корректно
то что ты написала, это условие остановки / бюджет, который получен аппроксимацией линейной
Этот вопрос в данном случае tricky. По факту нет простого одного ответа на всю работу. У нас на каждую итерацию оптимизации новая метрика - время работы на файлах разного размера. Когда мы не можем посчитать общую метрику на всю систему / исходную проблему, то мы можем воспользоваться промежуточными метриками. Их функция получается в том, чтобы помочь нам понять, была ли оптимизация успешна на данной итерации.
| Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации. | ||
|
|
||
| ## Feedback-Loop | ||
| Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за *не поняла как оценить время* |
There was a problem hiding this comment.
ну я бы тут оценивал сколько у тебя времени уходит на ожидание результата после запуска очередного варианта кода. если это секунд 10-15, то кайф, не нарушается состояние потока
| - Время выполнения на 20000: 2.843040 | ||
| - Время выполнения на 40000: 12.927038 | ||
|
|
||
| рост квадратичный -> O(n^2) |
| ### Ваша находка №4 | ||
| 1) продолжим использовать 640000 | ||
| 2) в топе самых долгих методов остается collect_stats_from_users (42%), посмотрим внутрь - там метод Date.parse (total 25%) | ||
| 3) заметим, что даты приходят в iso8601, поэтому можно опустить парсинг и сразу использовать |
| 6) поправим тест на перфманс (поставим границу 2.5 с) | ||
| 7) проверим время на 1млн: 3.760000 | ||
| 8) проверим на полном файле: 17.444283 секунд | ||
| 9) ради интереса проверим с выключенным gc: ~14 секунд |
There was a problem hiding this comment.
но чисто ради интереса, а то так и память может кончиться
|
|
||
| ## Результаты | ||
| В результате проделанной оптимизации наконец удалось обработать файл с данными. | ||
| Удалось улучшить метрику системы с ~23ч (предварительная оценка) до ~17.5 сек и уложиться в заданный бюджет. |
There was a problem hiding this comment.
респект за оценку исходного времени!
| end | ||
|
|
||
| describe 'Performance' do | ||
| it '80_000 works under 0.2s' do |
There was a problem hiding this comment.
it 'processes 80_000 lines under 0.2s'
| end.to perform_under(200).ms.warmup(2).times.sample(5).times | ||
| end | ||
|
|
||
| it 'has linear performance' do |
No description provided.