【问题标题】:Fast slicing .h5 files using h5py使用 h5py 快速切片 .h5 文件
【发布时间】:2014-05-09 16:05:24
【问题描述】:

我正在处理 .h5 文件,经验不足。

在我编写的脚本中,我从 .h5 文件中加载数据。结果数组的形状是:[3584, 3584, 75]。这里的值3584 表示像素数,75 表示时间帧数。加载数据和打印形状需要 180 毫秒。我使用os.times() 获得这个时间。

如果我现在想查看特定时间范围内的数据,我会使用以下代码:

data_1 = data[:, :, 1]

切片占用大量时间(1.76 秒)。我知道我的 2D 数组很大,但有时我想循环一段时间,因为我在 for 循环中执行这个切片需要很长时间。

是否有更有效/更省时的方式来分割时间框架或处理此类数据?

谢谢!

【问题讨论】:

  • 该数组实际上是在这 180 毫秒内加载的,还是只是一个模仿在文件顶部构造的数组的对象?如果每个像素 1 字节,没有压缩,没有开销,文件将占用将近 1GB 的大小。大多数 SSD 磁盘都达不到那种速度,大约是 5.4GB/秒。换句话说,切片操作是否实际上也在读取文件?
  • 嗯,这很好。完全忘记了。

标签: python arrays optimization h5py


【解决方案1】:

注意:我在这里做出假设,因为我不熟悉 .H5 文件以及访问它们的 Python 代码。

我认为正在发生的事情是,当您“加载”数组时,您实际上并没有加载数组。相反,我认为对象是在文件之上构建的。它可能会读取与文件组织方式相关的维度和信息,但不会读取整个文件。

该对象非常好地模仿了一个数组,以至于当您稍后执行切片操作时,可以执行正常的 Python 切片操作,但此时正在读取实际数据。这就是为什么与“加载”所有数据相比,切片需要这么长时间。

由于以下原因,我得出这个结论。

如果您正在阅读 75 帧 3584x3584 像素,我假设它们是未压缩的(H5 似乎只是数据的原始转储),在这种情况下,75 * 3.584 * 3.584 = 963.379.200,这大约 918MB 的数据。再加上你在 180 毫秒内“阅读”这个,我们得到这个计算:

918MB / 180ms = 5.1GB/second reading speed

注意,这个数字是针对 1 字节像素的,这也不太可能。

因此,这种速度似乎不太可能,因为即使是当今最好的 SSD 也远低于 1GB/秒。

似乎更合理的说法是,一个对象只是在文件之上构建,而切片操作会产生读取至少 1 帧数据的成本。

如果我们将速度除以 75 以获得每帧速度,则 1 字节像素的读取速度为 68MB/秒,而 24 或 32 位像素的读取速度则高达 270MB/秒。更合理。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-06-19
    • 2014-05-20
    • 1970-01-01
    • 1970-01-01
    • 2011-02-01
    • 2017-12-25
    • 1970-01-01
    相关资源
    最近更新 更多