You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current bundle weighs roughly 3.3 MB. Since it's basically a big binary, it's not tree-shakable by front-end tooling. I was wondering if it would be possible to maybe provide smaller, optimised bundles for specific use cases.
The main use case I'm thinking of is applications like myHDF5 that just read HDF5 files, and don't need all the APIs to write HDF5 files (create_dataset, etc.)
Also, my understanding is that currently, the WASM output includes three Emscripten file systems: MEMFS, IDBFS and WORKERFS. Perhaps it would be worth generating separate bundles for each as well?
I know that's a lot of potential combinations, especially when adding ESM/Node/IIFE to the mix... Perhaps there's a way to reorganise the code and the API to make use of dynamic linking or Module Splitting ... though this is all way over my head. 😅
The text was updated successfully, but these errors were encountered:
The extra filesystems don't add an appreciable amount of code, as I recall. The majority of the size comes from the hdf library itself. I spent some time trying to figure out how to reduce the size of the bundle in the past with very limited success. For comparison the DLL that ships with the h5py wheel for windows is also 3.3 MB.
Dynamic linking is a major headache and I don't see how it would help here - and Module Splitting is over my head too - I don't know what it does.
I tried an experiment where I eliminated all of the functions except one in the C library (list keys, making only a single call H5Literate into the HDF5 API), removed IDBFS and WORKERFS, and set the optimize mode to minimize size; the output file is still 3.2 MB in size.
I will have to look at how the HDF5 library is being compiled - maybe there is a way to reduce the size there.
The current bundle weighs roughly 3.3 MB. Since it's basically a big binary, it's not tree-shakable by front-end tooling. I was wondering if it would be possible to maybe provide smaller, optimised bundles for specific use cases.
The main use case I'm thinking of is applications like myHDF5 that just read HDF5 files, and don't need all the APIs to write HDF5 files (
create_dataset
, etc.)Also, my understanding is that currently, the WASM output includes three Emscripten file systems:
MEMFS
,IDBFS
andWORKERFS
. Perhaps it would be worth generating separate bundles for each as well?I know that's a lot of potential combinations, especially when adding ESM/Node/IIFE to the mix... Perhaps there's a way to reorganise the code and the API to make use of dynamic linking or Module Splitting ... though this is all way over my head. 😅
The text was updated successfully, but these errors were encountered: