Can WebAssembly Speed Up Browser File Scanning? A Real‑World Performance Study

Browser‑Side Binary Execution

WebAssembly is a binary file format (.wasm) designed to work alongside JavaScript; source code written in C/C++ (or other languages) can be compiled to this format and run directly in modern browsers.

When thinking of binaries on the web, the first reaction is faster execution. Although JavaScript JIT optimizations have improved speed, native‑level performance is still unattainable, and JIT effectiveness depends on code patterns, with several V8 optimization killers documented.

Practical Scenario

In QQ Enterprise Mail, the attachment upload feature scans a file before uploading to detect duplicates. The existing H5 FTN upload component, written in pure JavaScript, scans at >40 MB/s—more than twice the speed of the previous Flash+H5 component. Testing a 1.9 GB attachment took 20‑40 seconds, which is long for a quick‑upload path, prompting an investigation of WebAssembly’s potential benefits.

Emscripten Workflow

Following official guidance, the project uses Emscripten to compile to wasm. The overall flow from source to browser‑side wasm is illustrated below.

The core consists of three parts: LLVM, Emscripten, and the js/wasm/browser communication.

LLVM Overview

LLVM is a collection of SDKs that aid in building compilers and interpreters, focusing on the optimizer and backend stages rather than being a full compiler itself.

Example C source

test.c

:

<code>int main()
{
    int first = 3;
    int sum = first + 4;
    return 0;
}
</code>

Compiling with Clang produces LLVM IR (

test.ll

) that resembles low‑level instructions:

<code>define i32 @main() #0 {
  %1 = alloca i32, align 4
  %2 = alloca i32, align 4
  %3 = alloca i32, align 4
  store i32 0, i32* %1, align 4
  store i32 3, i32* %2, align 4
  %4 = load i32, i32* %2, align 4
  %5 = add nsw i32 %4, 4
  store i32 %5, i32* %3, align 4
  ret i32 0
}
</code>

Beyond performance, LLVM provides tools for code reuse, multi‑language support, and JIT, with documentation that is friendlier than GCC.

js/wasm/Browser Communication

Emscripten generates the wasm file, a JavaScript “glue” file, and optionally asm.js. The glue code loads the wasm module, creates a

Module

object, and exposes functions to JavaScript via

cwrap

or

ccall

. Typed arrays (HEAP8, HEAP16, HEAP32, etc.) map the wasm linear memory for data exchange.

Typical glue functions:

<code>function run(args) {
  if (runDependencies > 0) return;
  // ...
}
function doRun() {
  if (Module['_main'] && shouldRunNow) Module['callMain'](args);
}
</code>

After the main function runs, the runtime exposes a

Module

object that holds the wasm instance and memory buffers.

WebAssembly Performance Verification

A demo compares a wasm‑based hash implementation against fast JavaScript libraries (Rusha.js, YaMD5.js). The C interface declares

sha1_init

,

sha1_update

,

sha1_final

,

md5_init

,

md5_update

,

md5_final

. The update functions receive a pointer to a buffer allocated via

Runtime.stackAlloc

and its length.

JavaScript wrappers:

<code>const md5_init = Module.cwrap('md5_init');
const md5_update = Module.cwrap('md5_update', null, ['array','number']);
const md5_final = Module.cwrap('md5_final','string');
// similar wrappers for sha1
</code>

File reading uses

FileReader

to obtain an

ArrayBuffer

, which is then passed to the wasm functions. Benchmarks on a 530 KB file show wasm achieving 5‑8× speedup over pure JavaScript.

Online Code Refactor

To avoid blocking the UI, the H5 FTN component now uses Web Workers. Initially, workers handled both SHA‑1 and MD5 tasks, but message passing of large buffers dominated runtime, negating wasm’s advantage. By assigning each worker a fixed hash type (one for SHA‑1, one for MD5) and only transmitting the file chunk once, the overhead dropped dramatically.

After the change, the dominant costs per scan were a 6 ms initial buffer transfer and occasional 3 ms Promise.all overhead; the rest of the pipeline completed within 1 ms.

Production Results

For files larger than 500 MB, the wasm‑based scanner runs about 2.3× faster than the previous H5 implementation. A 1.9 GB test file scanned in ~12.1 seconds, achieving ~160 MB/s—roughly double the original speed.

Takeaways

WebAssembly is a standardized, browser‑supported binary format that can be extended quickly compared to waiting for new JavaScript features.

It excels at CPU‑intensive tasks but adds overhead for heavy control‑flow logic.

Performance gains are evident for chunk‑based processing; larger chunks can further leverage wasm’s speed, though loading overhead remains comparable to JavaScript.

Future applications of WebAssembly are promising as tooling matures.