-
Notifications
You must be signed in to change notification settings - Fork 88
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
feat: Implement cache for predictions #1334
base: master
Are you sure you want to change the base?
Conversation
Hello @DRMPN! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2024-12-17 08:51:30 UTC |
Code in this pull request still contains PEP8 errors, please write the Comment last updated at Tue, 17 Dec 2024 11:52:09 |
with closing(sqlite3.connect(self.db_path)) as conn: | ||
with conn: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Почему бы не реализовать DataCacheDB
как синглтон, подключаясь к БД один раз при инициализации (реинициализации в новых инстансах питона в многопотоке)?
Для pipeline и nodes уже есть кэширование, если правильно понимаю, поэтому сделал кэширование для метрик. По логам можно сделать вывод, что композирование работает быстрее без этого кэша. Я смотрел на параметр Возможно для более точных результатов эксперимента нужно увеличить количество запусков хотя бы 10 для каждого варианта, увеличить С кэшом метрик:
Без кэша метрик:
Еще раз с кэшом метрик:
|
Ты же вроде его модифицировал на кэширование данных?
А фактически сколько попаданий в кэш происходит? И сколько занимает одно обращение к нему? Если много - то кэш метрик можно держать в памяти, а не на диске. Да и данных тоже, если в этом проблема. Также можно задать какую-то специфическую начальную популяцию, где пайплайны сильно пересекаются по структуре. Так эффект кэша будет более заметен |
Сделал кэширование для промежуточных метрик, в текущем применении не заметил триггер. Сделал кэширование node для fit и predict. Прогнал несколько раз, при маленьком
30_min_out.txt Возможно для глубоких/широких пайплайнов (length >3) накапливается/появляется ошибка в кэше. |
Я
Для метрик в одном случае получилось 135 загрузок на 805 сохранений ~= 16.7%
Вроде видел, что можно создать список из нескольких пайплайнов и дать Федоту прогнать только их. Тогда он запустится без композирования и выберет самый оптимальный, да? Данный кэш именно с композированием сейчас работает. |
Ты написал что кэш на уровне узлов и пайплайнов уже есть. Но в этом PR-е он модифицирован, поэтому это тоже может влиять не эффективность.
Сохрани такую историю оптимизации и попробуй по ней конкретную ситуацию воспроизвести. |
Я про то, что можно задать такие начальные условия для структурной оптимизации, которые максимизируют пользу от кэша (если это нужно для тестирования). |
This is a 🙋 feature or enhancement.
Summary
⚠WIP⚠
DataCache
for composer.pipelines_cache
tooperations_cache
..pyc
files.Context
Resolves #1291