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

Homewor 1 #156

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

Homewor 1 #156

wants to merge 3 commits into from

Conversation

God1-ike
Copy link

@God1-ike God1-ike commented Jan 29, 2025

возникли какие-то проблемы с замерами итогового результата, вроде везде уже оптимизировал но итоговый не меняется по времени совсем.

Гружу на маке
2,3 GHz 8-Core Intel Core i9
16 GB 2667 MHz DDR4

Turbo Boost Switcher тоже поставил. Есть Варианты что может быть не так?

UPD.

Впринципе уложился, описал чут ьподробнее в дз

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.

nice work!

GB_OFF=1 FILE_SIZE=30000 ruby profilers/benchmark.rb
1.345629 0.993643 2.339272 ( 2.342273)
```
- проблема ушла, теперь на профилировщике видны новые точки роста
Copy link
Collaborator

Choose a reason for hiding this comment

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

главное что сложность исправли на линейную

```
определяем новую точку роста
- видно что больше всего времени опреация сбора уникальних браузеров через all?
- заменил постоянное сравнение all? на использование коллекции Set
Copy link
Collaborator

Choose a reason for hiding this comment

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

👍

определяем новую точку роста
- видно что больше всего времени опреация сбора уникальних браузеров через all?
- заменил постоянное сравнение all? на использование коллекции Set
- общее время вполенение сократилось с 12.06217939099588 до 6.39049573399825 в профилировщике.
Copy link
Collaborator

Choose a reason for hiding this comment

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

важно не смешивать профилирование и замеры времени

2) избежать повторные цциклы, подсчёетом всем каунтеров и сбором ифнормации в первом цикле
3) занёс логику сбора отчета прямиков в work из collect_stats_from_users для удобства и оптимизации
4) убрал лишние взаимодействия с пользователями, сделал чтобы они сразу создавали и записывались в виде объекта User
5) заменил способ загрузки файла на построчный File.readlines(data_file_path, chomp: true), ускорило процесс секунда на 10
Copy link
Collaborator

Choose a reason for hiding this comment

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

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

Удалось улучшить метрику системы с урезаных данных в виде 10_000 строк за 5-10 сек, до полный файл за 30 секунд и уложиться в заданный бюджет.

- надо активно следить за тем какие процессы запущены еще, они могут частично съедать ресурсы
- так же если делать всё в докере, то видно нужные еще более жесткие настройки образа, потмоу что я пытался играться версиями рубей через образы, он слишком много ресурсов отбирает и дополнительно ограничивает
Copy link
Collaborator

Choose a reason for hiding this comment

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

хм, я бы предложил без докера попробовать

у вас же наверно есть какая-то версия руби в системе, можно попробовать сравнить с докером и без

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

## Формирование метрики
Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я придумал использовать такую метрику: Файл размером 128M(3250940 строк) должен обрабатываться за 30 секунд.
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.

None yet

2 participants