WebAssembly中uintN与varuintN的区别、未替换原因及应用场景

Great question! Let's break this down step by step—understanding the tradeoffs between fixed-size (uintN) and variable-size (varuintN) integers in WebAssembly's binary format is crucial to seeing how Wasm balances efficiency and performance.

First, let's get clear on what each type does:

• Fixed-size uintN: This is a standard unsigned integer that takes exactly N/8 bytes of space, no matter the value. For example, uint32 always uses 4 bytes, whether you're storing 0 or 4294967295. Decoding it is trivial—just read the fixed number of bytes and interpret them as a binary integer.
• Variable-size varuintN: Uses the LEB128 encoding scheme to take up less space for small values. Each byte uses 7 bits to store data, with the 8th bit indicating if there's another byte coming. For example, a value less than 128 fits into 1 byte, while the maximum varuint32 takes 5 bytes. The catch? Decoding requires checking each byte's top bit until you reach the end, adding a small amount of overhead.

You might think variable-size integers are always better for saving space, but here's the thing—space efficiency isn't the only priority:

• Decoding performance overhead: For fields that need to be read quickly (like during module startup), the extra step of decoding varuintN adds unnecessary latency. If every field in the Wasm binary required LEB128 decoding, module load times would take a noticeable hit.
• Fixed offset reliability: Wasm's binary format relies on predictable byte offsets for certain structures. With uintN, you know exactly where the next field starts immediately after reading the current one. varuintN would force parsers to calculate offsets on the fly, complicating the parsing logic and introducing potential bugs.
• Worst-case space bloat: For large values, varuintN actually uses more space than uintN. A maximum uint32 fits in 4 bytes, but the same value as a varuint32 takes 5 bytes. If a field frequently holds large values, varuintN becomes a net loss.

These specific fields are all about startup speed and reliability—here's why fixed-size integers are non-negotiable for them:

• Magic Number (\0asm): This 4-byte uint32 is the first thing a Wasm loader reads to identify the file type. Using a fixed-size field lets the loader do a direct byte-for-byte comparison instantly, no decoding needed. This is critical for fast detection of Wasm modules (or non-Wasm files) during load.
• Version: The Wasm version number (currently 1) is stored as a uint32 right after the magic number. Loaders need to verify compatibility immediately, and a fixed-size field means they can jump straight to this value without decoding. Even if future versions increase, the fixed size ensures parsers never have to guess where the version field ends.
• Other fixed-purpose fields: Any field that needs to be parsed early in the module load process uses uintN for the same reason—minimizing startup latency and keeping parsing logic simple. These are the "foundation" fields that set up the rest of the module parsing, so speed and predictability matter more than space savings.

Hope that clears up the tradeoffs! It's all about picking the right tool for the job based on whether space efficiency or parsing performance is the higher priority for a given field.

内容的提问来源于stack exchange，提问作者Jason Yu