What are the differences between WASM_BINARY and WASM_BINARY_BLOATY

This code includes the compact WebAssembly binary (WASM_BINARY) and the uncompressed WebAssembly binary generated by the compiler (WASM_BINARY_BLOATY) in its compilation result, and the final executable binary for the project is generated.

What is the process to go form the bloaty binary to the compact one? Does it have to do with srtool?

1 Like

These kind of questions are better suited for https://substrate.stackexchange.com.

Nevertheless, the main difference between WASM_BINARY and WASM_BINARY_BLOATY is that the former is compressed and certain unneeded things are removed from the binary, e.g. certain sections from WASM.

1 Like

Where is the source code of stackexchange? Why would I ask questions on a proprietary platform while polkadot is hosting a free and open source software, namely Discourse?

I don’t like the Q&A way of documenting. Is there a place in the Substrate documentation explaining which sections are removed in the WASM_BINARY? If “code is documentation”, this means I should browse the code to get an answer?

What I can read in utils/wasm-builder/README.md:

This will include the generated Wasm binary as two constants WASM_BINARY and WASM_BINARY_BLOATY.

The former is a compact Wasm binary and the latter is the Wasm binary as being generated by the compiler.

Both variables have Option<&'static [u8]> as type.

What I can read in utils/wasm-builder/src/wasm_project.rs:

/// Compact the WASM binary using `wasm-gc` and compress it using zstd.
fn compact_wasm_file(
	project: &Path,
	profile: Profile,
	cargo_manifest: &Path,
	wasm_binary_name: Option<String>,
) -> (Option<WasmBinary>, Option<WasmBinary>, WasmBinaryBloaty) {

Ok, so subtrate is a project where instead of saying “RTFM” one should say “RTFC” because there is no f***ing manual but only f***ing code. Is my understanding correct?

How can you say this when you linked the exact documentation page for this subject in your original post?

I read this documentation entirely an it and find it incomplete. I am often forced to go read the code to get an answer. It’s not that I do not like to do it, but it makes harder to work with other people who are not as comfortable with reading the code as me.

We are completing the documentation in our own forum in French but I would rather contribute to an existing documentation, which I can not because of the level of detail of the current one.

1 Like

Fair point on the gap between the docs on the substrate.io and the ones in the code. Ultimately the docs.substrate.io should be comprehensive enough such that builders don’t need to rely on reading the code to understand various intricacies.

Could you help by stating what in your view is missing on the Build Process page that would help others understand things more clearly?

Could you please share a link to this initiative?

1 Like

I think the diagram is too schematic:


The operations “create” / “compact” / “compress” / “embed” should be put on the arrow instead of the circles and a description of the binaries should be added in the circles:

  • WASM runtime built by rustc
  • xx % (average or polkadot example) lighter runtime
  • xx % (average or polkadot example) lighter runtime

The names of the algorithms used for “compaction” and compression should be put along with the operations.

Concrete and specific examples, even restrictive, often allow to understand broader and more general concepts. That’s the power of illustration ^^

Our website is not yet documenting Substrate concepts since the current version of our software is a custom blockchain. But we are currently rewriting it in Substrate and discussing it on our forum.


I don’t know what embed means? Embed what?

It’s embedding the runtime in the node binary. It makes a single binary that contains both the node code and the runtime code.

1 Like

Okay. I mean I have written all of this code, but I didn’t get this. :wink:

We really need to improve this.

1 Like

Ok, sorry, I’m a substrate beginner, I’m just discovering the framework and the ecosystem and its contributors, I did not know you wrote all the code, but know I confirm I can see you everywhere in the commits :laughing:


Haha. I didn’t mean all the code, I mean the code related to the wasm builder. I also just wanted to express my surprise on what it means, but also wanted to use this as an argument that we need to improve the docs for this.


Thanks for the feedback.

Indeed, this diagram could be improved. Nice suggestions, I’ll relay this feedback to the original authors. Cheers sharing the links. :pray:

1 Like

@bkchr, that’s exactly why I’d like to get more help from engineering reviewing and improving the documentation.
To that end, can you provide the information being requested? It has been a while since I looked at this. For example, I don’t remember if it compression and compaction are separate processes/tools or just steps.
Changes requested:

  1. The name and relative size of the binaries in the diagram:
  • WASM runtime built by rustc
  • xx % (average or polkadot example) lighter runtime
  • xx % (average or polkadot example) lighter runtime
  1. The names of the algorithms used for “compaction” and compression should be put along with the operations.

Also, would something like “wrap” or “bundle” or “combine” be better than embed? (I think embed was in the original draft for the section and I just reused it.). Or can you suggest somehting easier to understand?