RFC: Use fewer objects in h5open and read

[jmert]

This PR closes most of the performance gap identified in reads from #752. The changes are:

1. Reuse the Datatype identified in each of the untyped read() functions when handing off to the generic typed-read. This is accomplished by renaming the generic read() to _read() and giving it both the HDF5 Datatype and the Julia Type as arguments.
2. Only create a new in-memory Dataspace if a hyperslab is being selected; otherwise, reuse the file Dataspace.
3. Only create the file access property list once in h5open, and only create a create-file property list if non-default options are being set (and close it if one was created).

Part of the performance gap appears to be due to libhdf5 v1.12 being a bit slower than v1.10, but if the library version is forced back to v1.10, each of the operations are on-par or faster than with HDF5.jl v0.13.7.

The RFC comes from the renaming of read() — I'm not sure just hiding the generic read as _read() is really the best option since it does make specializing on particular types require overloading the internal _read instead of public read if special data handling is required (as demonstrated by the _read(..., ::Type{Opaque}) case). Ultimately, though, it does seems some sort of similar structuring will be desired to retain the performance; might just need to iterate on the exact restructuring a bit.

(Note that the first commit is from #747 since both that PR and the changes here modify the opaque read method.)

[musm]

Yikes, by construction apl != DEFAULT_PROPERTIES, since apl[:fclose_degree] = H5F_CLOSE_STRONG on the line above.

[musm]

LGTM

[musm]

The RFC comes from the renaming of read() — I'm not sure just hiding the generic read as _read() is really the best option since it does make specializing on particular types require overloading the internal _read instead of public read if special data handling is required (as demonstrated by the _read(..., ::Type{Opaque}) case). Ultimately, though, it does seems some sort of similar structuring will be desired to retain the performance; might just need to iterate on the exact restructuring a bit.

Yeah I don't see a way to avoid that, but I also don't see this as a huge issue. How else would it be possible to allow such re-structing without the current signature were the Datatype is passed in as the second argument?

[jmert]

I guess the question if we're OK with the idea (and sitting on it for another day, no other alternative has come to me) would be should we allocate a better, more descriptive name than _read? generic_read might be better. It'd make describing in a future "dev docs" how to do an Opaque-like overload look more supported.

[musm]

generic_read might be better. It'd make describing in a future "dev docs" how to do an Opaque-like overload look more supported.

That sounds good to me generic_read or h5_read (I kind of don't like this as much)

I think as long as it's documented, having the second argument require the datatype pass though, should be fine IMO.

[jmert]

CI all green! 🎉

[musm]

I don't know why, but seeing all green checkmarks gives me a dopamine hit 🎉