# H5Dread performance issue with non-contiguous hyperslab selections

**URL:** <https://forum.hdfgroup.org/t/h5dread-performance-issue-with-non-contiguous-hyperslab-selections/2711>\
**Category:** Hdf-forum archives\
**Created:** [November 6, 2012, 7:37am UTC](https://forum.hdfgroup.org/t/h5dread-performance-issue-with-non-contiguous-hyperslab-selections/2711 "2012-11-06T07:37:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris\_LeBlanc](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/c/51bf81/32.png) [@Chris\_LeBlanc](https://forum.hdfgroup.org/u/Chris_LeBlanc)\
**Post date:** [November 6, 2012, 7:37am UTC](https://forum.hdfgroup.org/t/h5dread-performance-issue-with-non-contiguous-hyperslab-selections/2711/1 "2012-11-06T07:37:48Z")

</div>

Hi,

I think I've come across a performance issue with H5Dread when reading  
non-contiguous hyperslab selections. The use case in my software is a bit  
complicated, so instead I came up with a small example that shows the same  
issue. Please let me know if I'm missing something here, it's possible  
that a different approach could be much better.

In my example I write a 2D native int chunked dataset to an HDF5 file  
(adapted from the h5\_extend example, now writes a 229 MB file). I then  
construct a hyperslab selection of the dataset and read it back using a  
single call to H5Dread. When I use a stride of 1 (so all elements of the  
selection are contiguous) the read is very fast. However, when I set the  
stride to 2 the read time slows down significantly, on the order of 15  
times slower.

The dataset has a chunk shape of 1000x500, and the 0th dimension is the one  
being tested with a stride of 1 and 2. Is this a typical slowdown seen  
with a stride of 2? If the chunksize is 1000, then a stride of 1 and 2  
would still need to read the same amount of data, so I would expect similar  
performance.

I've run the stride of 2 scenario under Valgrind (using the callgrind tool)  
for profiling and it shows that 95% of the time is being spent in  
H5S\_select\_iterate (I can share the callgrind output if it helps), which is  
making this program CPU bound and nowhere near I/O bound. Any ideas on how  
to optimize this function or otherwise increase the performance of this use  
case?

Thanks,  
Chris LeBlanc

[h5dread\_hyperslab\_benchmark1.c](https://hdf-discourse-1.s3.amazonaws.com/original/1X/6692bccedb0abadd171b5f614e147cd013a8dde1.c) (5.34 KB)

---

<div class="post-metadata">

**Author:** ![su-loric](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/s/47e85d/32.png) [@su-loric](https://forum.hdfgroup.org/u/su-loric)\
**Post date:** [March 26, 2018, 6:56pm UTC](https://forum.hdfgroup.org/t/h5dread-performance-issue-with-non-contiguous-hyperslab-selections/2711/2 "2018-03-26T18:56:50Z")

</div>

A post was merged into an existing topic: [H5Dread performance issue with non-contiguous hyperslab selections](https://forum.hdfgroup.org/t/h5dread-performance-issue-with-non-contiguous-hyperslab-selections/2712)

---

<div class="post-metadata">

**Author:** ![su-loric](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/s/47e85d/32.png) [@su-loric](https://forum.hdfgroup.org/u/su-loric)\
**Post date:** [March 26, 2018, 6:56pm UTC](https://forum.hdfgroup.org/t/h5dread-performance-issue-with-non-contiguous-hyperslab-selections/2711/3 "2018-03-26T18:56:50Z")

</div>