WASM output size increased dramatically after using finalize_mall

[joshuajiangdev]

So after we introduce finalize_mall the size of the output jump from 105988 bytes to 1920836. Here is the repo to reproduce. You could comment out the line 20 in lib.rs and rebuild to see the size difference.

Here is the twiggy output:

 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼─────────────────────
       1114182 ┊    50.45% ┊ data[27]
        130051 ┊     5.89% ┊ code[58]
         36760 ┊     1.66% ┊ code[141]
         34324 ┊     1.55% ┊ code[124]
         33238 ┊     1.51% ┊ code[133]
         33160 ┊     1.50% ┊ code[134]
         26996 ┊     1.22% ┊ code[0]
         22455 ┊     1.02% ┊ code[4]
         15285 ┊     0.69% ┊ code[702]
         13561 ┊     0.61% ┊ code[24]
         12668 ┊     0.57% ┊ code[3]
         10724 ┊     0.49% ┊ code[31]
          8538 ┊     0.39% ┊ data[3]
          8232 ┊     0.37% ┊ code[1]
          8226 ┊     0.37% ┊ code[9]
          8226 ┊     0.37% ┊ code[10]
          8226 ┊     0.37% ┊ code[11]
          8158 ┊     0.37% ┊ code[12]
          8081 ┊     0.37% ┊ code[5]
          8074 ┊     0.37% ┊ code[2]
        659305 ┊    29.85% ┊ ... and 2521 more.
       2208470 ┊   100.00% ┊ Σ [2541 Total Rows]
       

[apoelstra]

I'm happy to leave this open but finalize_mall is inherently an extremely complicated operation, since it needs to analyze basically every possible PSBT field to find data that may be used for finalization, and then determine which data, and where to put it, is optimal.

I did a quick check of the code to see if we are gratuitously using generics, or something like that which we could easily fix, but it actually looks like a pretty concrete function. I think improvements are going to have to come from the wasm compiler rather than from us.

[joshuajiangdev]

I'm happy to leave this open but finalize_mall is inherently an extremely complicated operation, since it needs to analyze basically every possible PSBT field to find data that may be used for finalization, and then determine which data, and where to put it, is optimal.

I did a quick check of the code to see if we are gratuitously using generics, or something like that which we could easily fix, but it actually looks like a pretty concrete function. I think improvements are going to have to come from the wasm compiler rather than from us.

Thanks for fast reply! This makes sense. We also tried finalize_mut from the PsbtExt trait. They both have the similar size. I can also check with rust wasm side to see where is the root cause.

The biggest question I think is what are these 1.1 MB data.

[apoelstra]

Hmm, yeah, 1.1 in code wouldn't shock me because it's pulling in many functions that otherwise wouldn't be linked. But we shouldn't have anywhere near a meg in data.