Ok thanks! And how “bad” is that hdfread is still type unstable? I think there are functions that allow to preallocate the array making things potentially type stable. I would like to know if this is worth investigating or if my code is fine an I won’t gain anything.
I think the HDF5.jl package is still a work in progress. A great deal works but I’m currently stuck on how to append data, writing variable length strings, and how to make compound tables and fill them.
yes, there are some remaining pieces in HDF5.jl but my question is actually not that tight on that lib. Any IO reader will have this issue I described above.
It’s not really a problem that hdfread is type unstable because the time to do the type assert should be completely insignificant compared to the time it takes to execute hdfread
Not sure I understand. My issue is that I have several of these hdfread in my code and the first time I call it needs 1.7 seconds, the second requires 0.004762 seconds.
In the end I don’t personally care about type stability in this case. But I had the impression that type stable code is easier to compile (i.e. infer).
I didn’t know we were talking about compilation time… I haven’t gotten the impression that type stable code is faster to compile. In some sense, shouldn’t it be slower since you can do more optimizations with type stable code?
My global issue is that the UI application I am working on is not usable if it requires 2 minutes to start up and pressing a button the first time requires 20 seconds. Since pressing a button involves reading e.g. HDF5 file I was wondering if it would be a good idea to “clean up” the type unstable low level code in order to make my application start faster.