NetCDF slow writes when using the stride parameter.

[agnishd]

NetCDF versions in which we have observed this issue:

• Observed in 4.7.1, 4.6.3, and 4.3.3.1. There is a considerable improvement in 4.7.1 but, strided writes are still slower than just using loops and iteratively writing the same values at the same locations.

Platform information:

• Tested on Linux lsdbgl28141glnxa64 4.19.0-9-amd64 Netcdf cmake #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux

Description of the issue:

• We have observed slower write speeds when using the "nc_put_vars_double()" function to write to a NetCDF4-classic file using the "stride" feature. I created a standalone file to reproduce the issue and tested it on versions 4.7.3, 4.6.1, and 4.3.3.1 of the NetCDF library. The following are some sample runtimes that I got both by using the stride feature and without it:

ver 4.3.3.1:
Strided: 184514115 microseconds
Looped: 336884 microseconds

ver 4.6.1:
Strided: 175383093 microseconds
Looped: 340540 microseconds

ver 4.7.3:
Strided: 5841009 microseconds
Looped: 370361 microseconds

The code attached writes a 5184 x 228 x 40 matrix to a NetCDF file with dimensions: 5184 x 228 X (unlimited), using the nc_put_vars_double() function of NetCDF by:
a. Using the stride parameter i.e. specifying the stride vector as (1, 1, 5).
b. By looping along the z-axis and iterating the starting points of the writes as (0, 0, i * 5) while keeping the stride vector as (1, 1, 1).
NetCDF_slow_stided_writes-main.zip

[DennisHeimbigner]

This has been an ongoing issue.
See, for example: issue #1380
IF we ever can get a fix to that issue, it should significantly improve
strided performance for netcdf-4 file.

[edwardhartnett]

[agnishd]

Thanks for letting us know that this is an ongoing issue!

I just wanted to bring something else we found to your notice as well since I thought that it might be related to this issue.

Before testing the performance of strided writes on NetCDF4-classic files, I had tested the same out on NetCDF3 files by chance and got the following results:

1. 4.3.3.1:
   Strided: 7538865 microseconds
   Looped: 2355040 microseconds

2. 4.6.1:
   Strided: 7761987 microseconds
   Looped: 2531814 microseconds

3. 4.7.3:
   Strided: 6834903 microseconds
   Looped: 1505734 microseconds

Notice that the difference across versions isn't as stark as in the case of NetCDF4-classic files but strided writes are still slower compared to their looped versions.

I just had a few questions about this:

1. Is this known?
2. Is it a bug?
3. Or is this behaviour as per current expectations?

[DennisHeimbigner]

The problem is that when stride > 1, both netcdf-3 and netcdf--4 currently
devolve into walking the dataset one element at a time. This is where the time goes.
For netcdf-4, we have the option of using the HDF5 stride implementation which
is optimized to improve this case. We have, to date, not made such an optimization
available in netcdf-3, however. Hence it will likely remain slower than non-strided
until we can find the resources to fix it.

[agnishd]

Hello @DennisHeimbigner,

I just wanted to double-check if there have been any updates w.r.t to this issue yet. Do you have anything planned in one of your upcoming releases to address this if not?

[agnishd]

Hello @DennisHeimbigner,

We upgraded NetCDF to v4.8.1 and ran the repro code I sent you earlier on it and found that the issue is still there. I was wondering if there has been any update on this issue yet or if you have anything planned for a future release.

[DennisHeimbigner]

I had hoped that Ed Hartnett would fix this. But he is swamped with other work.
I will try to get to it as soon as feasible.

[edhartnett]

I have been investigating, and this issue has already been fixed. I have a test which deomonstrates.

I will put up the fix in a PR when current PRs are merged...

Here's a full report:

Issue #1877: NetCDF Slow Writes with Stride Parameter

#1877

Summary

Strided writes via nc_put_vars_double() were reported as orders of magnitude
slower than equivalent looped nc_put_vara_double() calls in NetCDF versions
4.3.3.1 through 4.7.x.

Root Cause

The slow path was NCDEFAULT_put_vars() in libdispatch/dvarput.c, which
handles strided writes by iterating element-by-element using an odometer loop,
calling NC_put_vara() once per element. For a 5184×228×40 array with stride 5
on the third dimension, this means ~47 million individual write calls.

The fast path is NC4_put_vars() in libhdf5/hdf5var.c, which calls HDF5's
H5Sselect_hyperslab() once to select the strided region, then issues a single
H5Dwrite() call.

Dispatch Table

For NetCDF-4/HDF5 files, the dispatch table in libhdf5/hdf5dispatch.c assigns
NC4_put_vars directly — so the fix was already in place. The 500–1000x
slowdown reported in older versions (4.3.3.1, 4.6.1) was likely due to those
versions routing through NCDEFAULT_put_vars.

Current Performance (this codebase)

Test: 5184×228 array, 40 z-slabs, stride 5 on unlimited dimension.

Method	Time
nc_put_vars_double() with stride 5	~12 s
Loop of nc_put_vara_double() calls	~1.3 s
Ratio	~9x

The 9x overhead is the inherent cost of a non-contiguous HDF5 hyperslab write
vs contiguous slab writes — not a bug. Before the fix (in older library
versions), the ratio was 500–1000x.

Why Not Always Use the Looped Workaround?

The looped workaround only works when:

• The stride is on a single dimension
• The data can be decomposed into contiguous slabs

nc_put_vars is a general API supporting arbitrary strides on all dimensions
simultaneously (e.g., stride (2, 3, 1)). The looped workaround cannot
replicate this without significant complexity and temporary buffer allocation.

Test Added

nc_test4/tst_strided_write.c — tests both correctness and performance:

1. Correctness: writes a 5184×228×40 array with nc_put_vars_double()
   stride (1,1,5), reads back with nc_get_vars_double(), verifies values.
   Same for the looped write. Both must match the source data exactly.

2. Performance regression (platforms with sys/time.h): measures both
   write methods and fails if strided is more than 20x slower than looped.
   This threshold catches a regression back to the one-element-at-a-time path
   (which would be hundreds of times slower) while tolerating normal HDF5
   hyperslab overhead.

Files Changed

• nc_test4/tst_strided_write.c — new test (created 2/22/26)
• nc_test4/Makefile.am — added tst_strided_write to NC4_TESTS
• nc_test4/CMakeLists.txt — added tst_strided_write to NC4_TESTS