-
Notifications
You must be signed in to change notification settings - Fork 9
Remove async initialization #29
Comments
You should try latest AS 0.9.1 which introduce drastically smaller runtime for now. Also currently uses also recommend remove this function and use this helper routine on js host |
Thanks for the suggestions. |
I guess reducing 100 bytes will not to be too hard. I'll try reduce this more later |
Or try replace all existing |
@MaxGraey curious what your thoughts are on the pattern of copying js buffers into/out of static wasm input/output buffers? Is it generally just more efficient to alloc on the wasm side if we can? Also curious about if |
I don't think so |
It would be really nice to provide a seemlessly interoperable interface to most known sha256 implementations but we currently are hindered in that regard by the async initialization currently required by our library. We need this async initialization of our wasm binary because our current build is >4kb, the limit set in Chrome for allowing synchronous initialization.
One avenue to pursue to hide this async initialization is to wait for top-level-await to land in typescript and in ecmascript.
Unfortunately, that seems like a multi-year solution to get into production across the environments we want to support (modern browsers and nodejs).
This technique also cannot hide the async initialization in the creation of multiple hash contexts (something we'd like to allow for to fix our currently async-unsafe API).
An alternative would be to remove the async initialization entirely by reducing our build below 4kb and simply initializing the wasm module synchronously.
I think we can easily get our build size lower than 4kb if we use a non-allocating interface and compile without the AS runtime. The pattern could go something like:
Thoughts?
@MaxGraey @mpetrunic @GregTheGreek @ec2
The text was updated successfully, but these errors were encountered: