Ниже я приведу конкретный пример, но это более общий вопрос о Joblib, на который я не смог найти ответ. Есть похожие вопросы, например этот о совместном использовании кеша Joblib, или этот , который пытается избежать копирования большого объектного объекта, доступного только для чтения, но я думаю, что они отличаются от чего я пытаюсь достичь
Мой сценарий использования следующий: У меня есть большой, глобально определенный, произвольный объект Python (в данном случае это набор панд Dataframes). Я хочу параллельно выполнять различные агрегации, не меняя большого объекта. Моя оптимизированная для памяти машина достаточно велика, чтобы помещать объект в память n раз, n это число доступных процессоров, поэтому я не должен быть связан памятью. Я нахожусь на Linux, то есть в любом случае я должен получить преимущество копирования при записи, но, как я понял, со сложными объектами, такими как кадры данных, я не могу действительно полагаться на это.
Стандартный способ выполнения моих вычислений с помощью Joblib (см. Код ниже) на самом деле значительно замедлил вычисления. Это улучшилось при передаче batch_size = 100 в Parallel (), но я на самом деле не совсем уверен, почему.
from joblib import Parallel, delayed
list_result_dfs = Parallel(n_jobs=8)(delayed(create_curve_comparison)(p) for p in parameters)
Что я делаю не так? В этом вопросе, вероятно, отсутствует информация, но я не знаю, что именно предоставить, поэтому, пожалуйста, спросите в комментариях, и я предоставлю это. Я не уверен, является ли заголовок правильным, но в настоящее время я предпочитаю, чтобы замедление происходило из-за того, что большой объект копируется, уничтожается и копируется снова для каждой итерации.