我必须对一叠图像的每个切片应用2D过滤器，我想并行化分析。但是，下面的代码比正常的for循环运行慢。另外，增加n_jobs也会增加处理时间，对于 n_jobs = 1 来说更快，而对于 n_jobs = 6 来说则更慢。
import numpy as np
from joblib import Parallel,delayed
from skimage.restoration import denoise_tv_chambolle
arr = np.random.rand(50,50,50)
def f(arr):
arr_h = denoise_tv_chambolle(arr,weight=0.1,multichannel=True)
return arr_h
Parallel(n_jobs=6,backend="threading")(delayed(f)(i) for i in arr)
Q ：（为什么）... 运行速度比普通for循环（？）
>>> import numpy as np; _ = np.random.rand( 50,50,50)
>>> from zmq import Stopwatch; aClk = Stopwatch()
>>>
>>> aClk.start(); r = denoise_tv_chambolle( _,weight = 0.1,multichannel = True ); b = aClk.stop(); print( "The code took {0: > 9d}[us]".format( b ) )
The code took 679749[us]
The code took 683137[us]
The code took 678925[us]
The code took 688936[us]
考虑到(50,50)-float64中的微型数据形状，缓存内计算是性能的关键。结合使用joblib.Parallel和' threading '后端是一种反模式（python使用 GIL -lock以便重新-[SERIAL]-使计算 一步一步 ，因为它避免了任何常见的并发相关冲突。这样的串行计算流程在这里变得更加糟糕，因为“转换” 一步一步 会产生额外的费用（不能纯粹地改善原始的{ {1}}代码执行-因此，您需要为获得相同的价格而付出更多的代价（但是，经过更长的时间））
Q ：增加
[SERIAL]也会增加处理时间
当然，由于存在更多的 n_jobs GIL导向的避免冲突，它会增加GIL锁重新[SERIAL]化开销的时间浪费” 切换 ”-过渡。
即使使用基于进程的并行机制（避免了GIL锁定的成本）进入完全成熟的并行机制，也要付出代价（同样要付出成本-进程实例化的成本（完整的1：1内存副本） python解释器进程在Win O / S中运行 one-step-after-another 次-与在Linux O / S中类似-如 n_jobs 模块中所述，包括建议避免产生其他形式的并行进程），参数数据传输成本，结果传输成本）。
如果一个人为 joblib 添加了所有这些附加费用，并且这些费用只是以一个微型计算任务的名义（如 n_jobs = 6 ），很快就会导致支付更多的费用来设置并行处理比将要收到的（其他效果-比原始的缓存重用更糟糕-不会“提高”计算速度）。
real-world costs ( and a due accounting for each class-of-(all-such)-costs ) of computing payloads 是原因 （Why）... 运行速度慢