d7dffc29649cdb642cc9b600634339551bfb6193 — Enric Meinhardt-Llopis 2 months ago 8f3c78b
clarify reason for hdf5 slowness (and remove rant)
1 files changed, 3 insertions(+), 23 deletions(-)

M Makefile
M Makefile => Makefile +3 -23
@@ 30,29 30,9 @@ ENABLE_JPEG = 1

# You can uncomment the line below to enable support for HDF5 files.
# However, notice that libHDF5 is an extremely user-hostile library and
# linking to it has major drawbacks in exchange of being able to open the
# stupid hdf5 files.  The real nightmare starts after version 1.10.3 of that
# library, which is based on the "fabric" framework.  Thus, linking against
# hdf5 turns each program into an "hdf5 application" that will perform
# several "checks" each time the program is run.  These checks are triggered
# by the mere dynamic loading of the library and cannot be disabled (even if
# the program does not use the library at all!).  On my laptop, this takes
# TWO HUNDRED FUCKING MILLISECONDS for each run of each program.  This is
# easily way longer than most actual image-processing computations, slowing
# all imscript-based pipelines to a crawl.  It's not that these checks do
# anything useful, either : if you strace the runtime linking of hdf5, you'll
# see that most of this time is spent in 961 calls to clock_nanosleep(2).
# My disappointment is immeasurable, and my day is ruined.
# On future versions of imscript, HDF5 support will be enabled by means of a
# middleman library that dynamically links libhdf5 upon demand.  Thus, only
# the first reading of an actual hdf5 image will be slowed-down.  But this
# is a lot of work and it will have to wait.
# CAVEAT: if you want to use HDF5, make sure that no "mpich" packages
# are installed on your computer.  If they are, all programs that link
# to libdf5 become really slow due to dynamic linking initialization.