scherbakov task #136
scherbakov task #136
Conversation
| - как вы решили её оптимизировать | ||
| - как изменилась метрика | ||
| - как изменился отчёт профилировщика - исправленная проблема перестала быть главной точкой роста? | ||
| - Больше всего времени(21%) занимает метод collect_stats_from_users, в частности Date.parse все тормозит. |
There was a problem hiding this comment.
На самом деле самое проблемное место Array.select, где N^2 проходов по массиву в поисках сессий
| - как изменился отчёт профилировщика - исправленная проблема перестала быть главной точкой роста? | ||
| - Больше всего времени(21%) занимает метод collect_stats_from_users, в частности Date.parse все тормозит. | ||
| - Посмотрел входные данные - увидел, что формат даты всегда одинаковый. значит вместо Date.parse можно использовать парсер, которому не нужно угадывать формат. | ||
| Заменил Date.parse(d) на Date.new(*d.split('-')) |
There was a problem hiding this comment.
с датой можно вообще ничего не делать
| то можно считать, что улучшилось на 200. set реально работает | ||
|
|
||
| ### Ваша находка №5 | ||
| - помимо метода readlines оставшееся время съедает некий Array.each... их в общем то в коде много, надо подумать как уменьшить проходы по спискам |
There was a problem hiding this comment.
в таких случаях желательно уточнить, какой именно из вызовов each самый проблемный (или map, или ещё что-то)
| - доля времени write выросла, each уменьшилась. большой файл все еще не читается | ||
|
|
||
| ### Ваша находка №6 | ||
| - в цикле users.each происходит еще один цикл users.select. это я глазом заметил и тут я начинаю подозревать, что ruby_prof мне выдает просто рандомные числа, |
There was a problem hiding this comment.
возможно у вас слишком маленький объём данных был для профилирования? практически все первым же делом видят, что array.select на первом месте с большим отрывом
|
|
||
| *Какими ещё результами можете поделиться* | ||
|
|
||
| ## Защита от регрессии производительности | ||
| Для защиты от потери достигнутого прогресса при дальнейших изменениях программы *о performance-тестах, которые вы написали* | ||
|
|
||
| Для защиты от потери достигнутого прогресса при дальнейших изменениях программы добавил тест, проверяющий выполняется ли программа менее чем за минуту. |
There was a problem hiding this comment.
да, если сделать алгоритм линейным, то можно аппроксимировать и сказать, что тест будет ок в случае если он обрабатывает 1/100 данных за 0.3с.
| 0.31 0.000 0.000 0.000 0.000 3 Array#sum | ||
| 0.28 0.000 0.000 0.000 0.000 1 Exception#initialize | ||
| 0.19 0.000 0.000 0.000 0.000 1 Exception#backtrace | ||
| 0.16 0.000 0.000 0.000 0.000 1 Exception#exception |
There was a problem hiding this comment.
что-то у вас не то с профилированием. Мб exception где-то происходил во время работы программы?
кол-ва calls очень маленькие. Если взять файл хотя бы на 10000 строк, и программа всё обрабатывает, то должны быть тысячи вызовов, а у вас их прям по несколько штук
| end | ||
| end | ||
| require 'oj' | ||
| require 'English' |
There was a problem hiding this comment.
это я хотел использовать oj для записи в файл, но метод Oj.to_file не добавлял в конце \n. я добавил его как #{$/}, а мне рубокоп Style::SpecialGlobalVars указа, что нужно использовать English
| 'browsers' => browsers.map(&:upcase).sort.join(', '), | ||
| 'usedIE' => browsers.any? { |b| b.upcase.include?('INTERNET EXPLORER') }, | ||
| 'alwaysUsedChrome' => browsers.all? { |b| b.upcase.include?('CHROME') }, | ||
| 'dates' => sessions.map { |s| s['date'] }.map { |d| Date.new(*d.split('-').map(&:to_i)) }.sort.reverse.map(&:iso8601) |
There was a problem hiding this comment.
с датой не надо на самом деле ничего делать
тут всего 2 коммита потому что я сделал прикол с распаковкой. у гитхаба ограничение на 100мб, а я закоммитил файл data_large.txt, он уже был в истории, и я не нашел ничего лучше чем создать новую ветку, перенести изменения и сделать merge --no-ff