Caching performance is worse than the one from the earlier versions

[IIaKyJIuH]

As for FEDOTv0.6.0 performance of the cache (both for operations and for preprocessors) has deeply regressed from the previous versions.
That can be seen from quality metrics on classification datasets - they're better when the cache is turned off...

It's important to accelerate a work of the cacher, so it would be reasonable to use it (It is enabled by default).

[valer1435]

<style> </style>

Yes cache					No cache
dataset	processes	pipelines count	ROC-AUC final	ROC-AUC cross-validation	dataset	processes	pipelines count	ROC-AUC final	ROC-AUC cross-validation
adult	1	13	0,897	0,9136	adult	1	14	0,8972	0,9126
adult	8	55	0,8965	0,9134	adult	8	60	0,896	0,9135
amazon_employee_access	1	44	0,8987	0,8393	amazon_employee_access	1	34	0,8972	0,8374
amazon_employee_access	8	273	0,8987	0,8418	amazon_employee_access	8	218	0,8987	0,8411
australian	1	401	0,9012	0,9419	australian	1	339	0,8992	0,9417
australian	8	2665	0,9003	0,9446	australian	8	2651	0,898	0,9447
bank-marketing	1	17	0,9188	0,9301	bank-marketing	1	19	0,9178	0,9298
bank-marketing	8	96	0,9175	0,9308	bank-marketing	8	115	0,918	0,9309
blood-transfusion-service-center	1	919	0,7447	0,7502	blood-transfusion-service-center	1	582	0,746	0,7461
blood-transfusion-service-center	8	3577	0,7422	0,7565	blood-transfusion-service-center	8	7582	0,745	0,7611
car	1	410	0,8325	0,9337	car	1	284	0,8212	0,9313
car	8	2115	0,8487	0,9365	car	8	2232	0,8472	0,9354
cnae-9	1	87	0,962	0,9939	cnae-9	1	78	0,962	0,9931
cnae-9	8	572	0,963	0,9948	cnae-9	8	567	0,965	0,9947
covertype	1	0	0,9715	0	covertype	1	0	0,9715	0
covertype	8	3	0,975	0,995	covertype	8	11	0,9788	0,9957
jungle_chess_2pcs_raw_endgame_complete	1	21	0,9023	0,9621	jungle_chess_2pcs_raw_endgame_complete	1	22	0,9042	0,9625
jungle_chess_2pcs_raw_endgame_complete	8	30	0,9103	0,9635	jungle_chess_2pcs_raw_endgame_complete	8	78	0,9048	0,9623
moons	1	462	0,9988	0,9989	moons	1	272	0,9987	0,9986
moons	8	2742	0,9992	0,9991	moons	8	1833	0,9987	0,999
numerai28	1	0	0,509	0	numerai28	1	5	0,5137	0,5198
numerai28	8	23	0,5265	0,5285	numerai28	8	23	0,5203	0,5245
phoneme	1	267	0,9318	0,9519	phoneme	1	197	0,9337	0,9523
phoneme	8	1099	0,933	0,9535	phoneme	8	971	0,933	0,9524
segment	1	293	0,983	0,9983	segment	1	201	0,983	0,9983
segment	8	1319	0,9827	0,9987	segment	8	1063	0,9805	0,9987
shuttle	1	43	1	0,9993	shuttle	1	27	1	0,9993
shuttle	8	238	1	0,9993	shuttle	8	274	1	0,9993
sylvine	1	205	0,9642	0,9803	sylvine	1	144	0,9627	0,9791
sylvine	8	772	0,9645	0,9827	sylvine	8	417	0,9648	0,9815
volkert	1	0	0,7815	0	volkert	1	4	0,795	0
volkert	8	21	0,8023	0,9315	volkert	8	18	0,8007	0,9299

Результаты актуальных экспериментов с кэшем - впринципе он работает, но есть некоторые проседания (особенно при многопроцессорном режиме). Думаю это связано с параллельным чтением/записью нескольких процессов и создание большого числа подключений к бд.

Какая идея есть

1. Сделать сброс в кэш после обучения всех пайплайнов в поколении, а во время обучения скидывать объекты в общую для всех процессов очередь. Думаю, что это никак не повлияет на эффективность, так как любые 2 пайплайна в поколении при мутациях чаще всего будут иметь какую-то общую часть (до ноды с мутацией). А после ноды с мутацией пайплайны будут различаться (а для кэша важно, какие были ноды ДО текущей операции). То есть, чтобы нода, стоящая за мутирующей нодой досталась из кэша - необходимо, чтобы пайплайн с МУТИРУЮЩЕЙ нодой уже был в кэше. Такое будет возможно, только если пайплайн с совпадающей структурой уже был в предыдущем поколении. Невозможно его достать из этого же поколения, так как мы не допускаем одинаковые пайплайны в поколении.

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

[valer1435]

Не актуально