Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ready #114

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

ready #114

Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions case-study.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
## Формирование метрики
Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я решил использовать такую метрику: Rspec тест проверяющий затрачиваемую память
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

когда говорим о метрике, надо больше акцент дать на то как именно вычисляется конкретное число. Например, если речь про затрачиваемую память - то как и когда мы получаем это число


## Гарантия корректности работы оптимизированной программы
Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации.

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

Вот как я построил `feedback_loop`: По примеру работы с первой задачей сделал выборки из data_large на

## Вникаем в детали системы, чтобы найти главные точки роста
Для того, чтобы найти "точки роста" для оптимизации я воспользовался *инструментами, которыми вы воспользовались*
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Вот какие проблемы удалось найти и решить

### Ваша находка №1
- какой отчёт показал главную точку роста
- как вы решили её оптимизировать
- как изменилась метрика
- как изменился отчёт профилировщика

### Ваша находка №2
- какой отчёт показал главную точку роста
- как вы решили её оптимизировать
- как изменилась метрика
- как изменился отчёт профилировщика

### Ваша находка №X
- какой отчёт показал главную точку роста
- как вы решили её оптимизировать
- как изменилась метрика
- как изменился отчёт профилировщика

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

*Какими ещё результами можете поделиться*

## Защита от регрессии производительности
Для защиты от потери достигнутого прогресса при дальнейших изменениях программы *о performance-тестах, которые вы написали*

### Ваша находка №1
При первом прогоне профайлера выявлено значительное потребление памяти на сложении массивов(более 70 процентов потребления).
sessions = sessions + [parse_session(line)] if cols[0] == 'session'
В комментариях к выполнению задачи было указание на переписывание программы на потоковый стиль.
Начнем сразу
т.к в файлах данных строгая последовательность пользователь-сессия-сессия, то можно заинициализировать класс и добавлять в него данные по мере наполнения, а после полного сбора привести их к требуемому формату
### Ваша находка №2
Таким образом мы обработаем второй тяжелый поинт из отчета не пробегая по массиву пользователей раз за разом
user_sessions = sessions.select { |session| session['user_id'] == user['id'] }
### Ваша находка №3
При очередном прогоне теста было замечено высокое потребление на моменте перебора строк файла через each. Написав небольшой бенчмарк для сравнения скорости работы методов чтения из файла был получен метод foreach который в 8 раз быстрее обрабатывает файл построчно.
### Ваша находка №4
Сначала я пытался добавлять пользователей в массив, дообогащать его рассчетами и записывать в файл преобразованное в json,
но при прогоне теста было большое потребление на обработку файловых операций.
Немного костыльными методами было решено разбить структуру предполагаемого файла на отдельные элементы, включая технические "{}, ", ," и дописывать в файл по мере необходимости.

## Результаты
В результате проделанной оптимизации удалось обработать файл с данными 1кк c целевыми показателями по использованной памяти. Причем показатели потребления не меняются при увеличении обьема данных.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## Примечания
При первой итерации пробовал пойти через перенос структуры данных в отдельные файлы. И гипотеза успешно отработала на файле до 1кк записей, но при увеличении объема затраты на запись и чтение свели весь прогресс на нет.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

да, постоянно читать-писать на диск это не варик

8 changes: 8 additions & 0 deletions profiler.rb
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
require_relative 'task-2.rb'
require 'benchmark'
require 'memory_profiler'

report = MemoryProfiler.report do
work(file_name: ARGV[0])
end
report.pretty_print(scale_bytes: true)
22 changes: 22 additions & 0 deletions profiler1.rb
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
require_relative 'task-2.rb'
require 'benchmark'
require 'ruby-prof'


RubyProf.measure_mode = RubyProf::ALLOCATIONS

result = RubyProf.profile do
work(file_name: ARGV[0])
end

printer = RubyProf::FlatPrinter.new(result)
printer.print(File.open('ruby_prof_reports/flat.txt', 'w+'))

# printer = RubyProf::DotPrinter.new(result)
# printer.print(File.open('ruby_prof_reports/graphviz.dot', 'w+'))

printer = RubyProf::GraphHtmlPrinter.new(result)
printer.print(File.open('ruby_prof_reports/graph.html', 'w+'))

printer = RubyProf::CallStackPrinter.new(result)
printer.print(File.open('ruby_prof_reports/callstack.html', 'w+'))
12 changes: 12 additions & 0 deletions ram_spec.rb
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
require 'rspec'
require 'rspec-benchmark'
require_relative 'task-2'

RSpec.describe 'work' do
include RSpec::Benchmark::Matchers

it 'requires < 60 Mb' do
work(file_name: 'data_large.txt')
expect((`ps -o rss= -p #{Process.pid}`.to_i / 1024)).to be < 60
end
end
Loading