Moment JavaScript zasáhl svůj výkonnostní strop Testování vizuální regrese je jedním z těch problémů, které zní jednoduše, dokud ho skutečně nezměníte. Vezměte si screenshot před změnou, vezměte si jeden po něm a rozptýlete je. Pokud se neshodují, něco se zlomí. Každý CI potrubí, které provádí vizuální testování, běží tisíckrát denně. JavaScript ekosystém má k tomu solidní nástroje. je standardní – malý, dostatečně rychlý pro většinu případů, nulová závislost. Je to dobře napsaná knihovna. Ale „dostatečně rychlý“ se začne rozpadat, když jsou vaše screenshoty v rozlišení 2K/4K, když provádíte srovnání dávek na stovkách stránek a když každá milisekunda v CI stojí penny. Pixelmatchová Chtěl jsem vytvořit něco efektivnějšího. Návrh algoritmu BlazeDiff Moje první myšlenka byla rozdělit obraz na bloky a úplně vynechat nezměněné oblasti.Většina UI screenshotů mezi běhy jsou 95% + totožné. Na první pohled to zní nemožně.Nemůžete vědět, zda se blok změnil, aniž byste se dotkli jeho pixelů. Ale většina obrazových algoritmů již používá levnou kontrolu úrovně bajtů před spuštěním nákladných percepčních srovnání. Vize spočívala v rozdělení těchto fází na dva samostatné průchody. V chladném průchodu se dotkněte každého pixelu, ale provádějte pouze levnou kontrolu, označte bloky jako změněné nebo nezměněné. Ale drahá práce běží pouze na 1-5% bloků, které se skutečně liší. : Architektura dvou průchodů 
 
 
 Studený průchod: Skenujte každý blok pomocí levného porovnání úrovně bajtů. Pokud se jakýkoliv pixel v bloku liší, označte jej jako změněný a pokračujte. Hot pass: iterujte pouze nad změněnými bloky. Spusťte plný percepční potrubí: výpočet YIQ barevné delta, detekce anti-aliasing sousedství, diff / AA barevný výstup renderování. Rozměry bloků s rozměry obrazu: 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)
}
 Malé snímky dostanou 8×8 bloků. 4K screenshot dostane 128×128 bloků. Vzorec zajišťuje, že bloky jsou vždy síly dvou (cache-line přátelský) a že granularita měří s plochou obrazu. Studený průchod je místo, kde většina zrychlení pochází. Pro 5600×3200 obraz s malou změnou rozhraní uživatele, můžete mít celkem 2000 bloků, ale pouze 15 obsahují rozdíly. Hot průchod, který provádí drahé výpočty, pokrývá méně než 1% obrazu. Zbývajících 99% dostane rychlé vyplnění šedé škály a pokračuje. Iterace na implementaci JavaScript První verze o Design založený na bloku přinesl významné zrychlení nad lineárním skenováním pixelmatch, ale samotný JavaScript se stal dalším bottleneckem. Bláznivý Prošla jsem několika optimalizacemi: 
 
 
 
 
 
 
 . 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 Implementace JavaScript skončila 1,5 krát rychleji než pixelmatch v průměru a až o 88% rychleji na identických obrazech. 
 
 
 
 
 
 
 
 
 
 
 
 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 obrazové rozlišení (rozdílné) 302 29 Kč 211 92 Kč 29 9 % 4K rozlišení obrazu (Ideální) 19.18 Kč 2.39 Kč 87,5 % Celá stránka (rozdílná část) 331 94 Kč 92,77 Kč 72,1 % Kompletní stránka (Ideální) 63,18 Kč 7,68 Kč 87,8 % Optimalizace založená na bloku jasně fungovala. Ale 211ms pro jeden 4K diff je stále pomalý, když běžíte stovky z nich. Objevování stropu: srovnání proti odiff Během benchmarku jsem zjistil, že — image diff nástroj napsaný v jazyce Zig s OCaml bindings. To bylo důsledně rychlejší než moje implementace JavaScript. Oděv To není překvapující. nativní kód má základní výhody: 
 
 
 
 Přímý přístup k paměti. Žádné přestávky sběrače odpadků. Žádné vytápění kompilace JIT. Kód běží přesně tak, jak byl kompilován. JavaScript nemá přímý přístup k vnitřním prvkům SIMD, jako je SSE4.1, AVX2 nebo NEON. WebAssembly vystavuje SIMD, ale stále přidává nadpisy ve srovnání s nativním kódem pro pracovní zatížení, jako je toto. Žádný V8 runtime, žádný event loop, žádné řetězce vyhledávání nemovitostí. Realita je jasná: jakmile je algoritmus optimalizován, jazyk a runtime se stávají omezujícím faktorem. Portujte algoritmus na odpočinek Rozhodnutí o přístavu do Rust se snížilo na několik faktorů: 
 
 
 
 
 Předvídatelný výkon. Žádný GC, žádný JIT ohřev, žádný skrytý overhead. Co píšete, je to, co běží. První třída intrinsics pro SSE4.1, AVX2/FMA, AVX-512 a NEON. Bezpečnost paměti. Nebezpečné bloky jsou explicitní a obsažené. Zbytek kódu dostane celoživotní a půjčovat kontrolu zdarma. Ecosystem. napi-rs pro spojení Node.js, rayon pro paralelismus, solidní cross-compilation příběh. Port Rust se řídí stejnou architekturou dvou průchodů. Zde je jádro chladného průchodu (část, která identifikuje, které bloky se změnily): // 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,
                );
            }
        }
    }
}
 Zrychlení SIMD je to, kde se věci stávají zajímavými. výpočet YIQ barevné delta (konverze rozdílů RGB na vnímání rozdílů) je nejžhavější vnitřní smyčkou. // 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
}
 Na x86_64 běží stejná logika jako SSE4.1 (4 pixely) nebo AVX2+FMA (8 pixelů), vybraná při spuštění. Detekce funkcí se provádí jednou za dif a pro celou operaci se používá nejrychlejší dostupná cesta SIMD. Původní port Rust se shodoval s výkonem na úrovni Odiff. Stejný algoritmus, jiný jazyk a najednou byl overhead běhu pryč. Optimalizace prochází: Výrazně rychlejší rust Matching odiff byl výchozí bod. Několik kol optimalizace tlačilo BlazeDiff daleko za ním. 
 
 
 
 
 
 
 
  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
 Výsledky proti odif (včetně úplného obrazu I/O: dekódování, dif, kódování): 
 
 
 
 
 
 
 
 
 
 
 
 
 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% Rozlišení 4K/1 (5600×3200) 119092 Kč 293 86 Kč 75.3% 4K / 2 1530.21 Kč 363 50 Kč 76.2% 4K / 3 183547 Kč 389 67 Kč 78.8% Celá stránka / 1 103520 Kč 47299 Kč 54.3% Celá stránka / 2 59879 Kč 26390 Kč 55.9% Kombinace blokového včasného výstupu, vektorizace SIMD, paralelního I/O a agresivní optimalizace kompilátoru. Integrační problém: Jak se dostat do JavaScript Mít rychlý Rust binární je skvělé. ale cílovými uživateli jsou vývojáři JavaScript psaní vizuálních testů s Playwright, Cypress nebo Vitest. Není . npm install cargo install První přístup byl zřejmý: Node.js → spawn binary → run diff → return result
 Obalte Rust binární do Node.js balíčku, spawn to jako dětský proces, a analyzovat výstup JSON: try {
  await execFileAsync(binaryPath, args);
  return { match: true };
} catch (err) {
  // Parse exit codes: 0=identical, 1=pixel-diff, 2=error
}
 To funguje. Je to jednoduché, přenosné a binární zpracovává veškeré těžké zvedání. Ale v potrubí CI, které se rozkládá na 500 snímků obrazovky, zplodíte 500 procesů. Vytvoření procesu není zdarma. Fork, exec, mapování paměti, sdílené nakládání s knihovnou. Převodovka na spawn je malá, ale přibývá. Benchmarks ukázaly, že jedí 30-40% z celkového času na malých snímcích, kde skutečný dif trvá <5ms. Proč ne vytvořit trvalý server? Odiff tento problém vyřeší spuštěním trvalého serverového procesu. Začnete ho jednou, pošlete diff žádosti přes zásuvku a zpracovává je bez spawn overhead. Přemýšlel jsem o tomto přístupu a odmítl ho. kompromisy se nehodily do případu použití: 
 
 
 
 
 Server znamená řízení životního cyklu: spustit ho před testováním, zastavit ho poté, vypořádat se s haváriemi a spravovat porty. Statefulness.Dlouhodobý proces akumuluje stav. Úniky paměti se stávají problémem (ve skutečnosti jsem se do toho dostal později s mimallocem). Integrace CI. CI prostředí jsou ephemeral. Přidání serveru daemon komplikuje Docker obrázky, GitHub akce pracovních postupů a vyřizování chyb. Chtěl jsem, aby každá operace byla atomová a autonomní. porovnat(a, b) by prostě mělo fungovat, aniž by bylo nutné, aby uživatel spravoval instance serveru. Designový cíl byl jasný: nativní výkon s jednoduchostí funkčního volání. Poučení z Rust-Based JavaScript Tooling Odpověď přišla ze studia toho, jak se s tímto problémem vypořádávají další nástroje JavaScript založené na systému Rust. (linter/formatter) používá obzvláště čistou architekturu: Bioměřice JavaScript API → N-API binding (.node file) → Rust core library
 Klíčovým pohledem je — Node.js je stabilní ABI pro nativní doplňky. Namísto zrodění procesu dítěte, kód Rust kompiluje na sdílená knihovna, která se nahrává přímo do procesu Node.js. Funkční volání z JavaScriptu na Rust se stávají přímými funkčními voláními. Žádná serializace, žádný IPC, žádný proces. N-API .node Platforma-specifické bináře jsou publikovány jako samostatné npm balíčky s a Na polích: os cpu {
    "name": "@blazediff/bin-darwin-arm64",
    "os": ["darwin"],
    "cpu": ["arm64"],
    "files": ["blazediff", "blazediff.node"]
}
 V hlavním balíčku jsou uvedeny jako : 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 instaluje pouze balíček odpovídající aktuální platformě. Žádné skripty po instalaci. Žádná kompilace. Pouze prebuilt binary. Konečná architektura: Rust + N-API BlazeDiffova konečná architektura používá vrstevný přístup. N-API vazba je rychlá cesta. 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
 Vázání N-API je definováno 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),
    })
}
 Na straně JavaScript se závazek lazily načte a vyrovná výsledek: 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;
}
 Konfigurace Cargo kompiluje stejný žebřík jako samostatný binární a cdylib (sdílená knihovna pro N-API): [lib]
name = "blazediff"
crate-type = ["lib", "cdylib"]

[features]
default = []
napi = ["dep:napi", "dep:napi-derive"]
 Jedna kódová základna, dva distribuční cíle: binární CLI a nativní modul Node.js. Stejné optimalizace SIMD, stejný algoritmus založený na blokech, stejné všechno, jen jiný vstupní bod. Poučení se naučilo Algoritmy před jazyky. Výběr správného algoritmu je důležitější než výběr správného jazyka.Kdybych šel přímo na Rust s přístupem pixel-by-pixel, měl bych rychlý skener pixelů namísto rychlého rozdílu obrazu. JavaScript má tvrdý strop pro numerickou práci. Jakmile byl algoritmus optimalizován, spouštěcí čas JavaScriptu – GC pauzy, JIT oteplování, nedostatek SIMD, řetězce vyhledávání nemovitostí – se stal dominantním nákladem. Pro těsné číselné kruhy nad velkými vyrovnávacími úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými úložnými údržbami. Architektura procesů je stejně důležitá jako design algoritmů. Skok od Rozhodnutí o architektuře – jak voláte kód, jak přenášíte data, jak spravujete životní cykly procesů – se s každým voláním zkomponují.Když rozptýlíte 500 snímků, rozdíl mezi voláním funkce a spawn je rozdíl mezi sekundami a minutami. spawn(binary) N-API je podhodnocený most. N-API poskytuje stabilní ABI ve všech verzích Node.js, čisté balení specifické pro konkrétní platformu prostřednictvím Je to stejný přístup, který používají Biome, SWC a další vysoce výkonné nástroje JavaScript.Pokud budujete knihovnu JavaScript kritickou pro výkon a samotný JavaScript je bottleneck, N-API + Rust je osvědčená cesta. optionalDependencies Benchmarkujte všechno, nevěřte ničemu. Každá optimalizace byla validována s referenčními hodnotami běžícími na konzistentním hardwaru. Cesta WASM byla zkoumána a opuštěna (ve skutečnosti jsem vyzkoušel Rust WASM a AssemblyScript – oba byly pomalejší než nativní pro tuto pracovní zátěž). JavaScript zůstává jedním z nejlepších ekosystémů pro vývojářské nástroje: příběh správce balíčků, integrace testovacích rámců a čistá šířka komunity. BlazeDiff lodě jako jeden Pod kapotou je 2 000 řádků Rust procesních pixelů optimalizovaných pro SIMD prostřednictvím algoritmu dvou bloků. . npm install compare(a, b) To je cíl: neviditelný výkon. Uživatel by neměl vědět nebo starat, že Rust existuje.

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

Read My Stories

Tento zvuk je produkován v původním jazyce příběhu!

Překonání limitů výkonu JavaScript s Rust a N-API: Vytvoření rychlejšího nástroje pro rozlišování obrázků

About Author

KOMENTÁŘE

ZAVĚŠIT ZNAČKY

TENTO ČLÁNEK BYL PŘEDSTAVEN V

Related Stories

Coinshift Launches csUSDL, Announces Strategic Partnerships

Coinshift Launches csUSDL, Announces Strategic Partnerships

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps