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

问题描述

我一直在使用以下代码构建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
    ]

在运行代码时，我注意到与完全并行处理（每个dask worker只有1个线程）相比，在并行并行处理中性能降低了10倍。我想这与GIL有关，我猜对任何人都没有真正的惊喜。 dask文档确实将其视为优化机会。拥有如此多的工作人员有一些缺点，因为他们现在的内存有限，要启动所有工作人员会增加额外的开销，更不用说更多的过程通信了。每个任务大约需要10秒钟，因此我不必担心dask.delayed的开销。

我有两个问题：

1. 底层CFGrib / Eccodes软件包中有什么可以改善多线程性能的东西吗？根据我的模糊理解，numpy等在基础编译代码中采取步骤来释放GIL？
2. 是否可以在dask中利用新的asyncIO python功能？ （我不是要任何人都要求立即开发此功能，我只是想知道是否存在或正在开发类似的东西，这是否是一个愚蠢的想法）

谢谢。

解决方法

如果您还没有看过它，我建议您看一下Xarray，至少看看它们如何处理Grib。