BigDataViewer Hdf5 Performance



Hello @hanslovsky, @tpietzsch

I have a question about Hdf5 (I am afraid it is rather an observation than a question…).

As far as I know even read methods in the java Hdf5 libraries are public static synchronized, implying that there can be only one read process in the whole JVM. Is that correct?

Is it then also correct to say that while Bdv is fetching data from different resolution layers there is one huge queue of processes that all want to access the one synchronized Hdf5 read method?
Which then would also means that any other process in the same JVM that want to do read Hdf5 files end up in the same waiting queue, which could potentially be kind of blocked by the processes going on in Bdv.

And I guess that’s why you like n5?

Would be great if you could shorty comment whether my understanding is correct.

Best, Christian


I am not too familiar with the HDF5 Java libraries. All I know is that parallel writing is non-trivial with HDF5 (not only the Java bindings), which was one of the reasons for N5.

Pinging @axtimwalde for comment.


Here is some info:

And one example from that page:

public synchronized static native int H5Dread(int fid, int filetype, int memtype, int memspace, Object data);


Christian, I think you are correct, unfortunately…


This made me think of BigDataServer: Do you think it makes conceptually sense to fire up a new BigDataServer for each client? Like this they would all have their own JVM and would not block each others Hdf5 read methods.


I think bad things happen as HDF5 itself doesn’t want to be read in parallel by default. The library has to be very explicitly compiled in parallel mode with one of a particular set of libraries. Serial HDF5 libraries will do a filesystem level lock to prevent multiple processes reading.


…really? that would be a problem!
do you know why one would do this?
I understand for writing, but reading?


Last time I tried I think there’s a read only flag that might allow parallel reads, but the filesystem in use disallowed file locks so it didn’t work as expected. HDF5 is best thought of as a hierarchical filesystem. The locks are likely to protect some global whatnots in the library.


I did some more digging as a sanity check. Multi-threaded reads to a single file (or even multiple files) require the thread-safe compilation. Reads are still serial due to global structures in library. Fully independent processes can read from the same file as long as nothing is writing. “Parallel HDF5” via MPI is incompatible with the thread-safe version.

So in theory spawning fully independent JVMs might work though I saw some references on stackoverflow to fork() not helping.