在线程中与DASK + CFGrib并行打开文件真的很慢

Question

我使用下面的代码构建了一个GRIB文件读取工具。我有异构文件，所以我不能使用xarray.open_mfdatasets或诸如此类的东西。

def create_open_delays(file_list: List[str],expected_dataset_count:int) -> List[Delayed]:
    """
    This function runs through list of files and creates a
    list of delayed open commands.
    """
    return [
        dask.delayed(cfgrib.open_datasets,nout=expected_dataset_count)(file,
                                           backend_kwargs={
                                               "indexpath": ""
                                           },
                                           cache=True) for file in file_list
    ]

在运行代码时，我注意到在线程并行中运行与完全进程并行相比性能下降了10倍(每个Dask工作者只有一个线程)。我猜这和吉尔有关，对任何人来说都没有真正的惊喜。DASK文档确实强调了这是一个优化的机会。有这么多工作人员有一些缺点，因为他们现在的内存有限，启动所有工作人员是额外的开销，更不用说更多的进程通信了。每个任务大约需要10秒，所以我不关心Dask.delayed的头等问题。

我有两个问题：

1. 在底层的CFGrib/Eccodes包中有什么可以改进多线程性能的吗？根据我的模糊理解，numpy等在底层编译代码中采取步骤来发布GIL？
2. 是否有可能利用DASK中新的asyncIO python功能？(我并不是要求任何人立即开发它，我只是想知道这样的东西是否存在或正在开发中，这是否是一个愚蠢的想法)

谢谢。

Answer 1

如果您还没有看到它，我建议您看看Xarray，至少看看它们是如何处理Grib的。