Skip to content

Оптимизация первого задания #146

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

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

KingeKod
Copy link

No description provided.

Copy link
Collaborator

@spajic spajic left a comment

Choose a reason for hiding this comment

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

👍

Я решил исправить эту проблему, оптимизировав эту программу.

## Формирование метрики
Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую линейную метрику, чтобы программа отрабатывала за линейное время выполнения в зависимости от размера входных данных.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Это не "метрика", это асимптотика. Метрика == число, вроде кол-во секунд или кол-во мегабайт, или кол-во IPS, ...

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

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

Choose a reason for hiding this comment

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

))

- expected block to perform linear, but performed exponential
- expected block to perform linear, but performed logarithmic
- expected block to perform linear, but performed power
Любые, но не линейная
Copy link
Collaborator

Choose a reason for hiding this comment

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

)) но кстати logarithmic - это лучше чем линейная

### Находка №2
- Опять же с помощью Flat увидел, что следующей точкой роста стал метод all?, котоый использовался при вычислении уникальных браузеров, вложенная цикличность
- Заменил эту вложенную цикличность each + all? на одиночный проход map и выборкой всех уникальных значений
- Для 10000 строк стало отрабатывать за 0.001084 сек. - было 0.196914 сек. -> в 180 раз? Вышел сильный прирост для небольшого объема данных
Copy link
Collaborator

Choose a reason for hiding this comment

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

при профилировании лучше давать программе поработать пару секунд хотя бы, чтобы уменьшить влияние погрешностей и дать покрутиться в основном цикле (если он есть)

- Для 10000 строк стало отрабатывать за 0.001084 сек. - было 0.196914 сек. -> в 180 раз? Вышел сильный прирост для небольшого объема данных
- Отчет профилировщика изменился, исправленная проблема перестала быть главной точкой роста

Так как для 10000 отрабатывает теперь очень быстро, изменил и увеличил Feedback-Loop, теперь стало отрабатывать для 100000 строк за 4.852382 сек, остановился на этом.
Copy link
Collaborator

Choose a reason for hiding this comment

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

👍

Так как для 10000 отрабатывает теперь очень быстро, изменил и увеличил Feedback-Loop, теперь стало отрабатывать для 100000 строк за 4.852382 сек, остановился на этом.

### Находка №3
- Тем же Flat профилировщиком увидел, что следующей тяжелой операцией является сложение массивов, т.е. метод "+", который вызывается при первом же each, где в массив собираются сессии и пользователи
Copy link
Collaborator

Choose a reason for hiding this comment

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

Flat это не профилировщик, а отчёт (просто обращаю внимание)


### Находка №4
- Flat профилировщиком показал, что следующая точка роста - это each. Для более понятной картины воспользовался CallTreePrinter, так как в древовидной структуре вызовов можно увидеть последовательность и понятное процентное соотношение затрат ресурсов конкретных методов. В метододе each вызываются map, однако их много, но из дерева видно, что трудозатратным в них является парсинг даты(Date.parse)
- Заменил Date.parse на Date.strptime, так как при парсе даты .strptime является более оптимальным методом
Copy link
Collaborator

Choose a reason for hiding this comment

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

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


Тест benchmark.rb проходит успешно, среднее время трех запусков программ с data_large.txt получается меньше 30 сек, а так же проверка на линейность perform_linear - выполняется

Если оптимизировать далее, то скорее придется переписывать программу, стараясь уменьшать кол - во итераций в программе.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Во втором задании можно зайти с другой стороны и получить интересные реузльтаты

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants