Analyze the pipeline-building capabilities of FEDOT

[nicl-nno]

Comparison with sklearn-pipelines 1) Memory consumption 2) Fit/inference time 3) Ability to build complex pipelines

[gkirgizov]

@IIaKyJIuH может, прикрепить сюда результаты ресерча, чтобы под рукой были?

[IIaKyJIuH]

В экспериментах по второму пункту получил по результатам прикреплённого питоновского файла, что FEDOT'овский медленнее значительно (см. прикреплённую картинку).

Использовалась только задача классификации. Пробовал пайплайны разной сложности.

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

• В 'bench_times.json' лежат получившиеся результаты по времени в зависимости от датасета и сложности пайплайнов
• В 'datasets_target_names.json' словарь: датасет -> название целевой колонки
• В файле с исходником можно изменять mean_range параметр для функции run_bench(...), она вызывается в самом низу

sklearn_bench.zip

Судя по json с результатами, разница по времени есть на порядок даже в маленьких датасетах. Кажется, что зависимость от объёма датасета никакая

[IIaKyJIuH]

Прикрепляю здесь архив с файлом pstats - результаты профилирования по среднему (размер, виды признаков и тд) датасету на простом пайплайне из лог. регрессии.

То есть, препроцессинг и в некоторых местах глубокое копирование тратят много времени.

output.zip

[IIaKyJIuH]

Для сравнения, вот относительные показатели отношения fedot/sklearn времени выполнения с выключенным препроцессингом: Mean fit time: 1.0237760102564102, mean inf time: 0.9280879076923078 А вот с включенным: Mean fit time: 30.451563958974365, mean inf time: 56.24433703846152

[nicl-nno]

Т.е. можно сказать, что без препроцессинга всё ок?

А кэширование препроцессора как-то позитивно влияет на это соотношение?

[IIaKyJIuH]

Да, без препроцессинга всё ок, он действительно забирал на себя всё основное время. Как ускорить его ещё не придумал. Вот типичный пример pstats по датасету (здесь приложен по APSFailure для простейшего пайплайна) без препроцессинга - output.zip

Кеширование тут даже не участвует, потому что используется сравнение готовых пайплайнов бок о бок. Если делать последовательные сравнения пайплайнов с сохранением препроцессоров на данных, то в этом будет профит. Выглядит нечестно, но можно проверить) В текущей реализации кешера препроцессоров это даже не получится, потому что ключом для препроцессора является descriptive_id от самого root_node. То есть, при разных (структурно) пайплайнах не получится им воспользоваться.

[IIaKyJIuH]

Ситуация странная получается, вот вроде бы на этом датасете ситуация явно в пользу ускоренной версии: results_adult_medium.zip

Однако, на некоторых получилось даже хуже: results_APSFailure_medium.zip

APSFailure намекает, что проблема в preprocessing.py::_clean_extra_spaces, однако, на тестах в колабе это не являлось узким местом...

и вообще сейчас почему-то в среднем по отношению времени выполнения fedot/sklearn получается просто нереально большой регресс)

[nicl-nno]

В среднем - это по всем датасетам?

А на каком датасете тогда хуже всего?

[IIaKyJIuH]

В среднем - это по всем датасетам?

А на каком датасете тогда хуже всего?

Да, в среднем по всем датасетам почему-то получается так.

Собрал максимальные показатели всё того же отношения: {'Fitting_time': ['higgs', 1663.365], 'Inference_time': ['robert', 4252.168]}

Получается, на далеко не самом большом датасете 'higgs' самый большой отрыв по фиттингу. И на 3-ем по объёму датасете - 'robert', самое большое отношение по инференсу.

Примечательно, что у 'robert' одни только числовые типы данных, поэтому странно, что он вообще нуждается в препроцессингах для object'ов. 'higgs' тоже состоит из чисел, но у него хотя бы треть колонок с типом object.