Week_1 cpu (Shlyapnikov A.)#151
Conversation
| gzip -dk fixtures/data_large.txt.gz | ||
|
|
||
| prepare_data: | ||
| head -n 1000 fixtures/data_large.txt > fixtures/data1000.txt |
|
|
||
| prepare_data: | ||
| head -n 1000 fixtures/data_large.txt > fixtures/data1000.txt | ||
| head -n 2000 fixtures/data_large.txt > fixtures/data2000.txt |
There was a problem hiding this comment.
fixtures лучше бы в gitignore добавить, чтобы не было 300к строк в PRе
| ## Формирование метрики | ||
| Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: *тут ваша метрика* | ||
| Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: | ||
| - обрабатывать 200_000 строк не больше чем за 1,5 сек, если я уложусь в это время, то обработка всего файла уложится в бюджет |
There was a problem hiding this comment.
в таких кейсах хорошо бы добавить чуть логики и арифметики - каким соотношением руководствуемся, какие числа и как получаем такой результат
There was a problem hiding this comment.
Наверное как то так?
Целевая метрика - мы хотим что бы полной отчет формировался(3250940) не более чем за 30 сек?
| "Processing time from file 1000000 rows: 41.2784" // полный отчет | ||
| ``` | ||
|
|
||
| Асимптотика финальная - видно что она почти линейная |
There was a problem hiding this comment.
ну она в принципе после первой итерации почти сразу и превращается в линейную
|
|
||
| ## Feedback-Loop | ||
| Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за *время, которое у вас получилось* | ||
| Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный `feedback-loop`, который позволил мне получать обратную связь по эффективности сделанных изменений за 5 минут(внес изменеия -> запустил бенчмарк и профилировщик-> посмотрел результат) |
| Удалось улучшить метрику системы с *9,36 до 1.3274* и уложиться в заданный бюджет(полный отчет формируется за 29.8777). | ||
|
|
||
| *Какими ещё результами можете поделиться* | ||
| 1. Пробовал запускать коллектинг данных по пользователям в несколько тредов(на кажый вызов `collect_stats_from_users(report, users_objects) do |user|` отдельный тред) - в моем случае это привело к регресу производительности с 37 сек. до 60 |
There was a problem hiding this comment.
с concurrency ещё будем разбираться в курсе
в целом в Ruby два треда не могут что-то считать одновременно; поэтому если задача именно в том чтобы что-то считать (а не ждать IO), то добавление треда не поможет, а скорее сделает хуже - как и произошло
но здорово, что проверили
| file_lines_count = file_lines.count | ||
|
|
||
| users_storage = {} | ||
| unique_browsers = Set[] |
lib/task-1.rb
Outdated
|
|
||
| # Даты сессий через запятую в обратном порядке в формате 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 } } |
There was a problem hiding this comment.
тут есть пасхалочка, что дата изначально в нормальном формате, поэтому с ней можно ничего не делать
There was a problem hiding this comment.
Спасибо! Слона то и не заметил, плюс ко всему это довольно замедляет программу.
Попробовал убрать и сразу - 8 сек на больших данных, было 29 стало 21
| @@ -0,0 +1,26 @@ | |||
| require 'ruby-progressbar' | |||
|
|
|||
| class ProgressBarFactory | |||
tests/task_perform_spec.rb
Outdated
| let(:time) { 1.5 } | ||
| let(:paths) { ['fixtures/data1000.txt', 'fixtures/data2000.txt', 'fixtures/data4000.txt', 'fixtures/data8000.txt'] } | ||
|
|
||
| shared_examples 'when create report' do |
There was a problem hiding this comment.
чот как-то сложно, мб без shared examples просто
it 'creates the report in expected time' do
...
end2 participants
No description provided.