瞬间的JavaScript击中了其性能上限 视觉回归测试是那些听起来很简单的问题之一,直到你实际上扩展它。在你的变化之前拍摄屏幕,接下一次,并分散它们。 JavaScript 生态系统为此提供了坚实的工具。 这是标准的 - 小,足够快,大多数情况下,零依赖性. 这是一个写得很好的库. 但“足够快”开始破裂,当你的屏幕截图是2K / 4K分辨率,当你在数百个页面上运行批量比较,当CI中的每毫秒都花费一分钱。 皮克斯 我想创造一些更有效率的东西。 设计BlazeDiff算法 我的第一个想法是将图像分成块,完全跳过不变的区域。 运行之间的大多数UI屏幕截图是95%以上相同的。 乍一看,这听起来是不可能的,你无法知道一个块是否改变,而不触摸它的像素。 但大多数图像差算法在运行昂贵的感知比较之前已经使用了廉价字节级别的检查。洞察力是将这些阶段分为两个单独的通道。在冷通道中,触摸每个像素,但只做廉价的检查,标记块变更或不变。 你仍然扫描每个像素一次,但昂贵的工作只运行在实际上不同区块的1-5%。 : 双通行架构 
 
 
 冷通行:使用廉价字节级别比较来扫描每个区块。如果区块中的任何像素不同,请将其标记为变更,然后继续。 热传输:仅在更改的块上迭代。运行完整的感知管道: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块. 公式确保块总是两个(缓存友好)的权力,而细微度与图像面积的规模。 冷通道是大多数加速的来源。对于具有小型用户界面变化的 5600×3200 图像,你可能总共有 2,000 个区块,但只有 15 个区别。 热通道,它执行了昂贵的计算,覆盖了不到 1% 的图像。 剩余的 99% 得到一个快速的灰度填充并继续。 在 JavaScript 应用程序上进行迭代 第一版的 基于区块的设计在pixelmatch的线性扫描上带来了显著的加速,但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图像(不同) 第3029章 第2192章 九九成 4K图像(相同) 第1818章 第393章 八百八十五 全页(不同) 第31394章 第977章 72. 百分比 完整页面(相同) 第318章 七八三 八七八成 基于区块的优化显然是有效的,但当你运行数百个区块时,单个4K差距的211ms仍然很慢。 发现天花板:与Odiff相比 在基准测试中,我发现 这是一个以Zig写的图像DIFF工具,具有OCaml绑定,它比我的JavaScript实现速度更快。 仇恨 这并不奇怪,原生代码有以下基本优势: 
 
 
 
 直接存储 没有垃圾收集器停机 没有 JIT 编译加热 代码正如编译一样运行。 JavaScript 没有直接访问 SIMD 内在元素,如 SSE4.1, AVX2 或 NEON. WebAssembly 暴露了 SIMD,但它仍然增加了与本地代码相比,对于这样的工作负载。 没有V8运行时间,没有事件循环,没有财产搜索链。 现实是明确的:一旦算法被优化,语言和运行时间就成为限制因素,你无法超越JavaScript的基本优化。 将算法转移到休息 港口到Rust的决定归结为几个因素: 
 
 
 
 
 可预测的性能. 没有GC,没有JIT加热,没有隐藏的头部。 支持 SSE4.1、AVX2/FMA、AVX-512 和 NEON 的第一类内在功能。 记忆安全. 不安全的块是明确的和包含的. 代码的其余部分得到终身和借贷检查免费。 生态系统. napi-rs for Node.js bindings, rayon for parallelism,坚实的交叉编译故事。 Rust 端口遵循相同的双通道架构. 以下是冷通道的核心(识别哪些块已经改变的部分): // 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 发生一次,并使用可用的最快的 SIMD 路径进行整个操作。 最初的 Rust 端口与 Odiff 级性能相匹配. 相同的算法,不同的语言,突然运行时间的过头消失了。 优化通道:使锈钢显着更快 匹配Odiff是基线,几轮的优化推动了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<(Image, Image), DiffError> {
    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
 对Odiff的结果(包括完整的图像I/O:解码,DIFF,编码): 
 
 
 
 
 
 
 
 
 
 
 
 
 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) 第11909章 第293章 75.3% 4K / 2 第1521章 第36350章 76.2% 4K / 3 第1835章 第389章 78.8% 全页 / 1 第103520章 第47299章 54.3% 全页 / 2 第5979章 第26390章 55.9% 在 4K 图像中速度更快 3 到 4 倍,基于区块的早期输出、SIMD 矢量化、并行 I/O 和积极的编译器优化相结合。 整合问题:在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个流程。 过程创建不是免费的。 ,exec,内存地图,共享库加载。 每粒子上空是小,但它增加了。 基准表显示,它在小图像上消耗了30%至40%的总时间,实际的分离需要 <5ms。 为什么不使用永久性DIFF服务器? odiff 通过运行一个持久的服务器流程来解决这个问题. 您启动一次,通过插件发送 diff 请求,并且它将其处理而不需要 spawn overhead。 我考虑了这种方法,并拒绝了它,妥协不适合使用案例: 
 
 
 
 
 服务器意味着生命周期管理:在测试前启动,之后停止,处理故障,并管理端口。 Statefulness. 一个漫长的过程积累了状态. 记忆泄露成为一个问题(我实际上后来与mimalloc参与了这件事)。 CI 集成. CI 环境是短暂的. 添加服务器戴蒙使 Docker 图像、 GitHub 操作工作流程和调试变得复杂。 API 设计. 我希望每一个 diff 操作都是原子和自含的。compare(a,b)应该只是工作,而不需要用户管理服务器实例。 设计目标是明确的:原生性能与函数调用的简单性。 学习基于Rust的JavaScript工具 答案来自研究其他Rust驱动的JavaScript工具如何处理这个问题。 (linter/formatter)使用一个特别干净的架构: 生物 JavaScript API → N-API binding (.node file) → Rust core library
 关键的见解是 — Node.js 的稳定 ABI for native addons. 代替生育一个孩子过程,Rust 代码将编译成一个 共享库,直接加载到 Node.js 进程中。从 JavaScript 到 Rust 的函数调用成为直接的函数指针调用。 N-API .node 包装策略同样重要,平台特定的二进制是以单独的 npm 包发布的。 和 场地: 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 只安装与当前平台相匹配的软件包. 没有后安装脚本. 没有编译。 最终架构: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 绑定是用 napi-rs 定义的: #[napi]
pub fn compare(
    base_path: String,
    compare_path: String,
    diff_output: Option<String>,
    options: Option<NapiDiffOptions>,
) -> Result<NapiDiffResult> {
    // 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;
}
 货物配置编译了与独立的二进制和cdylib(N-API的共享库)相同的起重机: [lib]
name = "blazediff"
crate-type = ["lib", "cdylib"]

[features]
default = []
napi = ["dep:napi", "dep:napi-derive"]
 一个代码库,两个分布目标:一个 CLI 二进制和一个 Node.js 原生模块. 相同的 SIMD 优化,相同的基于区块的算法,相同的一切,只是不同的入口点。 学到的教训 1、语言前的算法。 基于区块的设计在任何Rust编写之前在纯JavaScript中产生了72-88%的加速,选择合适的算法比选择合适的语言更重要。 JavaScript 对于数字工作有一个硬的上限。 一旦算法被优化,JavaScript的运行时间过剩(GC暂停,JIT加热,缺乏SIMD,财产搜索链)成为主导成本。对于紧张的数字循环,大缓冲,没有多少微优化可以克服V8过剩。 过程架构与算法设计一样重要。 跳跃从 对 N-API 的改进比一些算法上的改进更大。 架构决策 — 您如何调用代码、如何传输数据、如何管理过程生命周期 — 每一次调用都会加剧。 spawn(binary) N-API是一个低估的桥梁。 N-API 在 Node.js 版本中提供稳定的 ABI,通过清洁的平台特定包装 对于 Rust-to-JS 函数调用,它与 Biome、SWC 和其他高性能 JavaScript 工具使用的相同方法。如果您正在构建一个性能关键的 JavaScript 库,而 JavaScript 本身就是瓶颈,则 N-API + Rust 是一个经过验证的路径。 optionalDependencies 5、平衡一切,不相信任何东西。 每个优化都通过在一致的硬件上运行的基准进行验证。WASM路径被探索和放弃(我实际上尝试了Rust WASM和AssemblyScript,这两者都比本地工作量更慢)。 JavaScript 仍然是开发人员工具的最佳生态系统之一:包管理员的故事,测试框架集成和社区的广度,但有时最快的路径是让原生代码完成重大的提升,而 JavaScript 仍然是开发人员喜爱的界面。 BlazeDiff船只作为一个单身 在帽子下,它有2000行SIMD优化的Rust处理像素,通过双通区块算法。 . npm install compare(a, b) 这就是目标:看不见的性能.用户不应该知道或关心Rust的存在。

This story contains new, firsthand information uncovered by the writer.

Read My Stories

該音頻是用故事的原始語言製作的！

使用 Rust 和 N-API 突破 JavaScript 性能限制:构建更快的图像分辨工具

About Author

註釋

標籤

这篇文章刊登在

Related Stories

加密货币增长：创建有效的用户角色

Telegram：加密岛通往大陆的桥梁

使用这 18 种开发工具来提高你的工作效率 🚀🔥

成功云迁移的完整指南：策略和最佳实践

加密货币增长：创建有效的用户角色

Telegram：加密岛通往大陆的桥梁

使用这 18 种开发工具来提高你的工作效率 🚀🔥

成功云迁移的完整指南：策略和最佳实践

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps