Bundle size

[darioAnongba]

Hi all,

Working on the BDK-WASM project, we wrap BDK around wasm-bindgen and expose its API. We've been very surprised by the size of the final bundle: https://www.npmjs.com/package/@metamask/bitcoindevkit/v/0.1.7?activeTab=code

As can be seen, the generated WASM is >3.2MB, and that's applying all known size optimizations and doing a thorough work on it. Given that we expected BDK to easily integrate in small devices such as hardware wallets, the size is very surprising.

We currently bundle bdk_wallet and bdk_esplora. bdk_wallet alone produces a 2.3MB bundle, with Esplora it takes 3.2MB and best I could do is around 3.1MB by removing some code. It doesn't seem to be inherent to how WASM is compiled either as very small packages can be produced with wasm-pack.

Would be great to get your insights on what is causing this size and whether it can be improved.

Use case
Usage in browser extensions such as Mozilla Addons require files to be <4MB.

[darioAnongba]

ok so the best way to reduce bundle size is to use the secp-lowmemory feature of bitcoin as such:

bitcoin = { version = "0.32.5", default-features = false, features = [
    "secp-lowmemory",
] }

Reduced more than 1MB. Would be nice if someone knowledgeable could explain the downsides of this approach. @notmandatory ?

[rustaceanrob]

From the secp256k1 docs:

For example, the library uses context objects that contain precomputation tables which are created on object construction... the tables are optional, giving a performance boost for users who only care about signing, only care about verification, or only care about parsing

Precomputation tables, as per my rudimentary knowledge of curve implementations, are used to speed up the algorithm used to compute a * G for multiplications involving the generator point. From what I can tell, the global-context feature enables the use of these tables, but requires std. Enabling lowmemory appears to omit them, among other size optimizations. My guess is elliptic curve signatures may be slower as a result, but if your users do not sign thousands of messages, I don't think this would be noticeable.

[notmandatory]

Which tool have you been using to analyze the usage ? Have you tried twiggy ? I haven't used it but seems like the right tool to narrow down what's taking up the most space.

[notmandatory]

@afilini I recall you also ran into some no_std binary size issues but I can't find that issue. Did you make any discoveries that could help? I seem to recall our use of generics could have been a contributing factor to making code size larger than it needs to be.