Rust と N-API で JavaScript パフォーマンスの限界を打ち破る: より高速な Image Diff ツールの構築

The Moment JavaScript がパフォーマンスの上限を打った瞬間 Visual regression testing is one of those problems that sounds simple until you actually scale it. あなたの変更の前にスクリーンショットをとり、その後の1つをとり、それらを分散させます。 JavaScriptのエコシステムには、このための強力なツールがあります。 標準は小さい、ほとんどの場合には十分に速く、依存性はゼロです。それはよく書かれたライブラリです。しかし、「十分に速い」は、あなたのスクリーンショットが2K/4Kの解像度であるとき、あなたが何百ページにわたってバッチ比較を実行しているとき、およびCIの毎ミリ秒が1セントの費用がかかるときに破裂し始めます。 ピクセル もっと効率的なものを作りたいと思いました。 BlazeDiffアルゴリズムの設計 私の最初のアイデアは、画像をブロックに分割し、変更のない領域を完全に飛ばすことでした。 実行間のほとんどのUIスクリーンショットは95%+同一です。 なぜボタンの色を変更するために1800万ピクセルをスキャンするのですか? 最初に見ると、これは不可能なように聞こえます. ピクセルに触れずにブロックが変わったかどうかを知ることができません。 しかし、ほとんどの画像ディフラアルゴリズムは、高価な感覚比較を実行する前にすでに安価なバイトレベルのチェックを使用しています。その洞察力は、これらの段階を2つの別々のパスに分割することでした。冷たいパスでは、ピクセルごとに触れるが、安価なチェックのみを行い、ブロックを変更または変更しないようにマークすることでした。ホットパスでは、標識されたブロックでのみ高価な作業を実行します。 しかし、高価な作業は実際に異なるブロックの1〜5%でしか実行されません。 : 2 パス・アーキテクチャ Cold Pass: 安価なバイトレベルの比較を使用して各ブロックをスキャンします. ブロック内のピクセルが異なる場合は、変更としてマークし、進めます. ブロックが完全に同一であれば、すぐにグレースケール出力を描いてそれを忘れてください。 ホットパス:変更されたブロックの上にのみイテレートします。完全な感覚パイプラインを実行してください:YIQ色デルタ計算、反変異近隣検出、diff/AA色出力レンダリング。これは高価な作業であり、実際に変更した画像のわずかな部分だけに触れます。 ブロックサイズスケールは画像サイズで: export function calculateOptimalBlockSize( width: number, height: number, ): number { const area = width * height; const scale = Math.sqrt(area) / 100; const rawSize = 16 * Math.sqrt(scale); // More efficient power-of-2 rounding using bit operations const log2Val = Math.log(rawSize) * LOG2_E; return 1 << Math.round(log2Val); // Bit shift instead of Math.pow(2, x) } 小さな画像は8×8ブロックを得ます。4Kスクリーンショットは128×128ブロックを得ます。この公式は、ブロックは常に2つのパワー(キャッシュラインフレンドリー)であり、細部性は画像の領域とスケールすることを保証します。 冷たいパスは、スピードアップのほとんどがどこから来ているかです。 5600×3200の画像と小さなUI変更は、合計2000ブロックを持っているかもしれないが、15の違いだけが含まれています。高価な計算を実行するホットパスは、画像の1%未満をカバーします。残りの99%は、急速なグレースケールの充填を得て移動します。 JavaScript Implementationについて 最初の版 of ブロックベースのデザインは、ピクセルマッチの線形スキャンを上回る大幅なスピードアップをもたらしたが、JavaScript自体が次のボトルネックとなった。 ブレイク いくつかの最適化パスを通過しました: . The image data is / , but the YIQ color comparison needs to work on 32-bit RGBA pixels. Casting to via lets you read a full pixel in one operation instead of four-byte reads. Typed arrays everywhere Uint8Array Uint8ClampedArray Uint32Array DataView . Pre-allocating the array, avoiding intermediate buffers, reusing output buffers across comparisons. Minimizing allocations changedBlocks . Before doing any work, check if the two image buffers are literally the same reference. This catches the “nothing changed” case in constant time: Buffer identity check Buffer.compare( Buffer.from(image1.data.buffer), Buffer.from(image2.data.buffer) ); . Keeping the hot inner loop as tight as possible with no function calls, no conditionals that the branch predictor can't handle, and no unnecessary property lookups. Loop structure JavaScript の実装は、平均してピクセルマッチよりも 1.5 倍速く、同じ画像では 88% まで速くなりました。 Benchmark pixelmatch BlazeDiff Improvement 4K image (different) 302.29ms 211.92ms 29.9% 4K image (identical) 19.18ms 2.39ms 87.5% Full page (different) 331.94ms 92.77ms 72.1% Full page (identical) 63.18ms 7.68ms 87.8% 4K画像(異なる) 302.29ミリ 211 92 マス 29.9% 4K画像(同一) 19.18ミリ 2.39ms 87% 全ページ(異なる) 331.94ms 92.77ms 72.1% 全ページ(同一) 63.18ミリ 768Ms 87.8 % ブロックベースの最適化は明らかに機能していましたが、単一の 4K ディフのための 211ms は、それらの数百台を実行しているときにまだ遅いです。 天井を発見する:Odiffに対する比較 ベンチマークをしてみると、発見した — an image diff tool written in Zig with OCaml bindings. It was consistently faster than my JavaScript implementation. それは私のJavaScript実装よりもずっと速かった。 オディフ ネイティブコードには基本的な利点があります: Direct memory access. No garbage collector pauses. No JIT compilation warmup. コードはコンパイルされた正確な方法で実行されます。 JavaScript は、SSE4.1、AVX2、または NEON のような SIMD インテリジェンスに直接アクセスできません。WebAssembly は、SIMD を暴露しますが、このようなワークロードのネイティブ コードに比べて、まだオーバーヘッドを追加します。 V8 ランタイムなし、イベントロープなし、不動産検索チェーンなし。 現実は明らかです:アルゴリズムが最適化されると、言語とランタイムが制限要因になります。 Porting the algorithm to Rust(アルゴリズムを休める) Rustへのポートへの決定は、いくつかの要因によって下された: 予測可能なパフォーマンス. No GC, no JIT warmup, no hidden overhead. What you write is what runs. SSE4.1、AVX2/FMA、AVX-512、およびNEONのためのファーストクラスの内部機能。 メモリのセキュリティ 非安全なブロックは明示的で含まれている コードの残りは生涯無料でチェックし、借りられます。 エコシステム. napi-rs for Node.js bindings, rayon for parallelism, solid cross-compilation story. Node.js bindings, rayon for parallelism, solid cross-compilation story. Rust ポートは同じ 2 つのパスアーキテクチャに従います. Here is the core of the cold pass (the part that identifies which blocks have changed): // Cold pass: identify changed blocks for by in 0..blocks_y { for bx in 0..blocks_x { let start_x = bx * block_size; let start_y = by * block_size; let end_x = (start_x + block_size).min(width); let end_y = (start_y + block_size).min(height); let has_diff = block_has_perceptual_diff( a32, b32, width, start_x, start_y, end_x, end_y, max_delta, ); if has_diff { changed_blocks.push((start_x, start_y, end_x, end_y)); } else if let Some(ref mut out) = output { if !options.diff_mask { fill_block_gray_optimized( image1, out, options.alpha, start_x, start_y, end_x, end_y, ); } } } } SIMDの加速は、物事が興味深くなる場所です。YIQ色のデルタ計算(RGBの違いを感覚的な違いに変換)は、最も熱い内部ループです。 // Load four pixels at once and extracts RGB channels using vector instructions before computing the YIQ perceptual delta. #[cfg(target_arch = "aarch64")] unsafe fn yiq_delta_4_neon(pixels_a: *const u32, pixels_b: *const u32) { let pa = vld1q_u32(pixels_a); // Load 4 RGBA pixels let pb = vld1q_u32(pixels_b); // Extract channels let r_a = vandq_u32(pa, mask_ff); let g_a = vandq_u32(vshrq_n_u32(pa, 8), mask_ff); let b_a = vandq_u32(vshrq_n_u32(pa, 16), mask_ff); // Convert to float for YIQ transform let r_a_f = vcvtq_f32_u32(r_a); // Alpha blending with FMA let br_a = vfmaq_f32(v255, vsubq_f32(r_a_f, v255), alpha_norm_a); // YIQ: y²×0.5053 + i²×0.299 + q²×0.1957 } x86_64 では、ランタイムで選択された SSE4.1 (4 ピクセル) または AVX2 + FMA (8 ピクセル) と同じ論理が実行されます。 機能検出は diff ごとに 1 回発生し、利用可能な最速の SIMD パスが全操作に使用されます。 最初の Rust ポートは odiff レベルのパフォーマンスと一致しました. 同じアルゴリズム、異なる言語、そして突然、ランタイムのオーバーヘッドがなくなりました。 Optimization Passes: Making Rust Significantly Faster Matching odiff was the baseline. いくつかのラウンドの最適化はBlazeDiffをそれ以上に推し進めた。 The cold pass block comparison got its own SIMD path. Instead of computing the full YIQ delta for every pixel in a block, use SIMD byte comparison first. If any bytes differ, fall through to the perceptual check. This makes the cold pass nearly free for identical blocks. SIMD tuning. Blocks are processed in row order to maximize L1/L2 cache hits. The image data is stored as contiguous RGBA bytes, so scanning blocks left-to-right, top-to-bottom follows the memory layout. Cache-aware block traversal. The image is interpreted as via a zero-copy cast. No allocation, no copy: Minimizing memory copies. &[u32] Image loading (PNG decoding via vendored libspng, JPEG decoding via libjpeg-turbo) runs in parallel using rayon: Parallel I/O. fn load_images(path1: P1, path2: P2) -> Result { if fmt1 == fmt2 { return match fmt1 { ImageFormat::Png => load_pngs(&path1, &path2), ImageFormat::Jpeg => load_jpegs(&path1, &path2), }; } let results: Vec = [ (path1.as_ref().to_path_buf(), fmt1), (path2.as_ref().to_path_buf(), fmt2), ] .par_iter() .map(|(path, fmt)| match fmt { ImageFormat::Png => load_png(path), ImageFormat::Jpeg => load_jpeg(path), }) .collect(); Ok((iter.next().unwrap()?, iter.next().unwrap()?)) } Fat LTO, single codegen unit, abort on panic, symbol stripping: Release profile. [profile.release] opt-level = 3 lto = "fat" codegen-units = 1 panic = "abort" strip = true オディフに対する結果(完全な画像I/Oを含む:デコード、ディフ、コード): Benchmark odiff BlazeDiff Improvement 4K/1 (5600×3200) 1190.92ms 293.86ms 75.3% 4K/2 1530.21ms 363.50ms 76.2% 4K/3 1835.47ms 389.67ms 78.8% Full page/1 1035.20ms 472.99ms 54.3% Full page/2 598.79ms 263.90ms 55.9% 4K/1(5600×3200) 119092位 293.86ミリ 75.3% 4K / 2 1530・21ミリ 36350mS 76.2% 4K / 3 1835.47 メートル 389・67ミリ 78.8% 全ページ / 1 1035.20ミリ 472・99mS 54.3% 全ページ / 2 598.79 マス 26390円 55.9% 4K画像で3〜4倍速く、ブロックベースの早期出力、SIMDベクター化、パラレルI/O、そして攻撃的なコンパイラ最適化の組み合わせが加わります。 The Integration Problem: Getting Rust into JavaScript について 速いRustバイナリを持つことは素晴らしいですが、ターゲットユーザーはJavaScript開発者がPlaywright、Cypress、またはVitestで視覚テストを書くことです。 ノー . npm install cargo install 最初のアプローチは明らかなものでした: Node.js → spawn binary → run diff → return result Rust バイナリを Node.js パッケージに巻き込んで、子どものプロセスとして生成し、JSON 出力を解析します。 try { await execFileAsync(binaryPath, args); return { match: true }; } catch (err) { // Parse exit codes: 0=identical, 1=pixel-diff, 2=error } これは機能します。それはシンプルでポータブルで、バイナリはすべての重いリフトを処理します。しかし、CIパイプラインで500スクリーンショットを消すと、あなたは500プロセスを生み出しています。プロセス作成は無料ではありません。フォーク、エクス、メモリマッピング、共有ライブラリのロード。スパウンドあたりのオーバーヘッドは小さいが、それに加算します。ベンチャーマークは、実際のディフが5ms以下である小さな画像の合計時間の30〜40%を食べていることを示しました。 なぜ永続的なDIFFサーバーがないのか? odiff はこの問題を解決し、持続的なサーバープロセスを実行します. You start it once, send diff requests over a socket, and it handles them without the spawn overhead. Odiff はこの問題を解決します。 私はこのアプローチを検討し、それを拒否しました. 妥協は使用例に合わなかった: サーバーとは、ライフサイクル管理を意味します:テスト前に開始し、テスト後に停止し、クラッシュを処理し、ポートを管理します。 Statefulness. A long-running process accumulates state. Memory leaks become a problem (I actually ran into this later with mimalloc). 長く続くプロセスによって、状態が蓄積されます。 CI 統合. CI 環境はエフェミリアルです. サーバー デーモンを追加すると、Docker 画像、GitHub アクション ワークフロー、およびデバッグが複雑になります。 API 設計. I wanted each diff operation to be atomic and self-contained. compare(a, b) should just work, without requiring the user to manage server instances. 私は、それぞれの diff 操作が原子的で自己含まれるようにした。 デザインの目標は明確でした:機能呼び出しのシンプルさとネイティブなパフォーマンス。 Rust-Based JavaScript Tooling から学ぶ 答えは、他のRust 対応の JavaScript ツールがこの問題をどのように扱っているかを調べることに由来しました。 (the linter/formatter) uses a clean architecture: 特にクリーンなアーキテクチャを使用しています。 バイオ JavaScript API → N-API binding (.node file) → Rust core library 鍵となる洞察は、 — Node.js の安定 ABI for native addons. Instead of spawning a child process, the Rust code compiles to a native addon Node.js プロセスに直接ロードする共有ライブラリ. JavaScript から Rust への関数呼び出しは、直接の関数ポインタ呼び出しになります. No serialization, no IPC, no process overhead. N-API .node パッケージング戦略も同様に重要です. Platform-specific binaries are published as separate npm packages with そして フィールド: os cpu { "name": "@blazediff/bin-darwin-arm64", "os": ["darwin"], "cpu": ["arm64"], "files": ["blazediff", "blazediff.node"] } 主要パッケージはこれらを : optionalDependencies { "name": "@blazediff/bin", "optionalDependencies": { "@blazediff/bin-darwin-arm64": "3.5.0", "@blazediff/bin-darwin-x64": "3.5.0", "@blazediff/bin-linux-arm64": "3.5.0", "@blazediff/bin-linux-x64": "3.5.0", "@blazediff/bin-win32-arm64": "3.5.0", "@blazediff/bin-win32-x64": "3.5.0" } } npm/pnpm/bun は、現在のプラットフォームと一致するパッケージのみをインストールします. No postinstall scripts. No compilation. Just a prebuilt binary. 最終アーキテクチャ:Rust + N-API BlazeDiffの最終的なアーキテクチャは、階層化されたアプローチを使用します。N-APIの結合は、高速パスです。 JavaScript API ↓ Try N-API binding (in-process, ~0 overhead) ↓ (if unavailable) Fall back to execFile (spawn binary) ↓ Rust diff engine ↓ SIMD + parallel I/O N-API binding is defined with napi-rs: N-API binding is defined with napi-rs: #[napi] pub fn compare( base_path: String, compare_path: String, diff_output: Option , options: Option , ) -> Result { // Load images in parallel using rayon let (img1, img2) = load_images(&base_path, &compare_path)?; // Run the diff let result = diff(&img1, &img2, output_image.as_mut(), &diff_options)?; Ok(NapiDiffResult { match_result: result.identical, reason: if result.identical { None } else { Some("pixel-diff".into()) }, diff_count: Some(result.diff_count), diff_percentage: Some(result.diff_percentage), }) } JavaScript 側では、バンドリングは怠慢にロードし、結果をキャッシュします。 let nativeBinding: NativeBinding | null = null; let nativeBindingAttempted = false; function tryLoadNativeBinding(): NativeBinding | null { if (nativeBindingAttempted) return nativeBinding; nativeBindingAttempted = true; const key = `${os.platform()}-${os.arch()}`; const platformInfo = PLATFORM_PACKAGES[key]; if (!platformInfo) return null; try { const require = createRequire(import.meta.url); const binding = require(platformInfo.packageName) as NativeBinding; if (typeof binding?.compare === "function") { nativeBinding = binding; return binding; } } catch { // Native binding not available, will use execFile fallback } return null; } The Cargo configuration compiles the same crat as both a standalone binary and a cdylib (shared library for N-API): [lib] name = "blazediff" crate-type = ["lib", "cdylib"] [features] default = [] napi = ["dep:napi", "dep:napi-derive"] One code base, two distribution targets: a CLI binary and a Node.js native module. 同じSIMDの最適化、同じブロックベースのアルゴリズム、同じすべて、単に異なる入力ポイント。 学ぶレッスン 言語の前にアルゴリズム ブロックベースのデザインは、Rust が書かれる前に、純粋な JavaScript で 72-88% のスピードアップを生み出しました。正しいアルゴリズムを選ぶことは、正しい言語を選ぶことよりも重要です。 JavaScript には、数値作業のための厳しい上限があります。 アルゴリズムが最適化されると、JavaScriptのランタイムオーバーヘッド(GCの休憩、JITの温暖化、SIMDの欠如、プロパティ検索チェーンの欠如)が主なコストとなりました。 大きなバッファを超える緊密な数値ロープでは、マイクロオプティミズムの量がV8のオーバーヘッドを克服することはできません。 これはJavaScriptの批判ではありません。 それは異なるツールが異なる目的を果たしているという認識です。 プロセスアーキテクチャはアルゴリズム設計と同じくらい重要です。 ジャンプ from N-API は、いくつかのアルゴリズムの変更よりも大きな改善となりました。アーキテクチャの決定 — コードをどのように呼び出し、データをどのように転送するか、プロセスライフサイクルをどのように管理するか — は、各呼び出しで複合されます。 spawn(binary) N-APIは過小評価の橋です。 N-API は、Node.js バージョンにわたって安定した ABI を提供し、クリーンプラットフォーム特有のパッケージを提供します。 , and near-zero overhead for Rust-to-JS function calls. It's the same approach used by Biome, SWC, and other high-performance JavaScript tools. If you're building a performance-critical JavaScript library and JavaScript itself is the bottleneck, N-API + Rust is a proven path. あなたがパフォーマンスに重要なJavaScriptライブラリを構築し、JavaScript自体がボトルネックである場合、N-API + Rustは実証済みのパスです。 optionalDependencies 5.すべてをベンチマークし、何も信じない すべての最適化は、一貫したハードウェア上で実行されているベンチマークで検証されました。 WASM ルートは探検され、放棄されました(実際には、Rust WASM と AssemblyScript の両方を試してみました - どちらもこのワークロードのネイティブよりも遅かった)。 JavaScriptは、開発者向けのツールのための最良のエコシステムの1つであり、パッケージマネージャーのストーリー、テストフレームワークの統合、そしてコミュニティの広さです。 BlazeDiff ボート シングル キャップの下には、2つのパスブロックアルゴリズムを通じてSIMDに最適化されたRust処理ピクセルの2000行があります。 . npm install compare(a, b) それが目的です:見えないパフォーマンス. ユーザーはRustが存在することを知る必要はありません。