Momentul în care JavaScript a atins plafonul de performanță Testarea regresiei vizuale este una dintre acele probleme care sună simplu până când o scalezi de fapt. Luați o captură de ecran înainte de schimbarea dvs., luați-o după aceea și difuză-le. Dacă nu se potrivesc, ceva se rupe. Fiecare conductă CI care face testarea vizuală rulează de mii de ori pe zi. Ecosistemul JavaScript are instrumente solide pentru a face acest lucru. este standardul – mic, suficient de rapid pentru majoritatea cazurilor, zero dependențe. Este o bibliotecă bine scrisă. Dar „suficient de rapid” începe să se rupă atunci când capturile de ecran sunt de rezoluție 2K/4K, când rulați comparații de lot pe sute de pagini și când fiecare milisecundă în CI costă un ban. pixelă Am vrut să construiesc ceva mai eficient. Descrierea algoritmului BlazeDiff Prima mea idee a fost să împart imaginea în blocuri și să treacă complet regiunile neschimbate. Cele mai multe capturi de ecran UI între runde sunt 95% + identice. De ce să scanați 18 milioane de pixeli pentru o schimbare de culoare a butonului? La prima vedere, acest lucru pare imposibil.Nu poți ști dacă un bloc s-a schimbat fără a-și atinge pixelii. Dar majoritatea algoritmilor de imagine difuză folosesc deja o verificare la nivel de byte ieftin înainte de a rula comparații perceptuale scumpe. Înțelegerea a fost de a împărți aceste etape în două trepte separate. În trecerea rece, atingeți fiecare pixel, dar faceți numai verificarea ieftină, marcând blocurile ca fiind schimbate sau neschimbate. Cu toate acestea, munca costisitoare rulează doar pe 1-5% din blocuri care diferă de fapt. : Arhitectura cu două trepte 
 
 
 Cold Pass: Scanarea fiecărui bloc folosind o comparație la nivel de byte ieftin. Dacă orice pixel dintr-un bloc diferă, marcați-l ca fiind schimbat și continuați. Hot Pass: Iterați numai pe blocurile schimbate. Rulați întreaga conductă perceptuală: calcularea delta a culorii YIQ, detectarea vecinătății anti-aliasing, redarea ieșirii de culoare diff / AA. Aceasta este munca costisitoare și atinge doar o fracțiune mică a imaginii care sa schimbat de fapt. Dimensiunile blocului cu dimensiunile imaginii: 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)
}
 Imaginile mici obțin 8×8 blocuri. O captură de ecran 4K obține 128×128 blocuri. Formula asigură că blocurile sunt întotdeauna puteri de două (cache-line prietenos) și că granularitatea scalează cu suprafața imaginii. Pentru o imagine de 5600×3200 cu o schimbare mică a UI-ului, s-ar putea să aveți 2.000 de blocuri în total, dar numai 15 conțin diferențe. Hot-pass-ul, care efectuează calculele scumpe, acoperă mai puțin de 1% din imagine. Restul de 99% primește o umplere rapidă la scară gri și continuă. Când nimic nu sa schimbat, cold-pass-ul respinge imediat fiecare bloc. Introducere în implementarea JavaScript Prima versiune a Designul bazat pe blocuri a dat viteze semnificative peste scanarea liniară a pixelmatch-ului, dar JavaScript însuși a devenit următoarea barieră. Blazești Am trecut prin mai multe pași de optimizare: 
 
 
 
 
 
 
 . 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 Implementarea JavaScript a fost de 1,5 ori mai rapidă decât pixelmatch în medie și până la 88% mai rapidă pe imagini identice. 
 
 
 
 
 
 
 
 
 
 
 
 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% Imagini 4K (diverse) 302.29 de secunde 211.92 milioane de lei 29,9 % din Imaginea în 4K (Ideală) 19,18 milioane 2,39 milioane 87,5 % din Pagina completă (diferențiată) 331.94 de secunde 92.7 milioane de lei 72,1 % din Pagina completă ( identică) 63.18 milioane 7,68 milioane 87,8 % din Optimizarea bazată pe blocuri a funcționat în mod clar.Dar 211ms pentru o singură diferență 4K este încă lentă atunci când rulați sute de ele.Și în acest moment, algoritmul în sine a fost optimizat. Descoperirea plafonului: comparație împotriva odiff În timpul benchmarking-ului, am descoperit — un instrument de imagine dif scris în Zig cu legături OCaml. A fost în mod constant mai rapid decât implementarea mea JavaScript. Odif Acest lucru nu a fost surprinzător. codul nativ are avantaje fundamentale: 
 
 
 
 Acces direct la memorie. Nu există pauze ale colectorului de gunoi. Nu există încălzire a compilației JIT. Codul rulează exact așa cum a fost compilat. JavaScript nu are acces direct la elementele intrinseci SIMD, cum ar fi SSE4.1, AVX2 sau NEON. WebAssembly expune SIMD, dar adaugă totuși o suprapunere în comparație cu codul nativ pentru sarcini de lucru ca aceasta. Nu există timp de rulare V8, nu există ciclu de evenimente, nu există lanțuri de căutare a proprietăților. Realitatea este clară: odată ce algoritmul este optimizat, limba și timpul de rulare devin factorul limitator. Portarea algoritmului la repaus Decizia de a porni la Rust s-a redus la câțiva factori: 
 
 
 
 
 Performanță previzibilă. Fără GC, fără încălzire JIT, fără suprafață ascunsă. Ce scrieți este ceea ce rulează. Primă clasă intrinsec pentru SSE4.1, AVX2/FMA, AVX-512 și NEON. Securitatea memoriei. Blocurile nesigure sunt explicite și conținute. Restul codului primește o verificare de viață și împrumut gratuit. Ecosistem. napi-rs pentru legături Node.js, rayon pentru paralelism, poveste solidă de compilare încrucișată. Portul Rust urmează aceeași arhitectură cu două treceri. Aici este miezul trecerii reci (partea care identifică blocurile care s-au schimbat): // 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,
                );
            }
        }
    }
}
 Accelerarea SIMD este locul în care lucrurile devin interesante. Calculul delta de culoare YIQ (conversia diferențelor RGB în diferențe perceptuale) este cea mai fierbinte buclă interioară. // 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
}
 Pe x86_64, aceeași logică funcționează ca și SSE4.1 (4 pixeli) sau AVX2 + FMA (8 pixeli), selectate la timpul de execuție. Detectarea caracteristicilor are loc o dată pe dif, iar cel mai rapid traseu SIMD disponibil este utilizat pentru întreaga operațiune. Portul Rust inițial a corespuns performanței la nivel odiff. Același algoritm, limbă diferită și brusc timpul de rulare a dispărut. Optimizarea trece: Faceți rugina semnificativ mai rapidă Matching odiff a fost baza. Mai multe runde de optimizare au împins BlazeDiff departe de ea. 
 
 
 
 
 
 
 
  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
 Rezultatele împotriva odiff (inclusiv imaginea completă I/O: decodare, diff, codare): 
 
 
 
 
 
 
 
 
 
 
 
 
 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 milioane de lei 293.86 milioane de lei 75.3% 4K / 2 1530.21 secţiuni 363,5 milioane 76.2% 4K / 3 1835.47 de secunde 389.67 de secunde 78.8% Pagina completă / 1 105.20 de secunde 472.99 milioane de lei 54.3% Pagina completă / 2 598.79 milioane de lei 263.90 de milioane 55.9% 3-4x mai rapid pe imagini 4K. Combinația dintre ieșirea timpurie bazată pe blocuri, vectorizarea SIMD, I/O paralelă și optimizarea compilatorului agresiv se adaugă. Problema integrării: obținerea rupturii în JavaScript Având un rapid Rust binar este mare. dar utilizatorii țintă sunt dezvoltatorii JavaScript care scriu teste vizuale cu Playwright, Cypress sau Vitest. nu . npm install cargo install Prima abordare a fost cea evidentă: Node.js → spawn binary → run diff → return result
 Înfășurați binarul Rust într-un pachet Node.js, spawn-l ca un proces copil și analizați ieșirea JSON: try {
  await execFileAsync(binaryPath, args);
  return { match: true };
} catch (err) {
  // Parse exit codes: 0=identical, 1=pixel-diff, 2=error
}
 Acest lucru funcționează. Este simplu, portabil, iar binarul se ocupă de toată ridicarea grea. Dar într-o conductă CI care difuzează 500 de capturi de ecran, naști 500 de procese. Crearea procesului nu este gratuită. Fork, exec, cartografiere a memoriei, încărcare partajată a bibliotecii. Overhead-ul pe spawn este mic, dar se adaugă. Benchmarks-urile au arătat că a mâncat 30-40% din timpul total pe imagini mici în cazul în care difuzarea reală durează <5ms. De ce nu un server diferențiat permanent? Odiff rezolvă această problemă executând un proces de server persistent. îl porniți o dată, trimiteți cereri dif peste un socket și le prelucrează fără suprapunerea spawn. Am luat în considerare această abordare și am respins-o. Compromisurile nu se potrivesc cazului de utilizare: 
 
 
 
 
 Un server înseamnă gestionarea ciclului de viață: începeți-l înainte de testare, opriți-l după, gestionați eșecurile și gestionați porturile. Un proces de lungă durată acumulează starea. scurgerile de memorie devin o problemă (am intrat de fapt în acest lucru mai târziu cu mimalloc). Integrarea CI. Mediile CI sunt efemere. Adăugarea unui daemon de server complică imaginile Docker, fluxurile de lucru GitHub Actions și debugging-ul. Am vrut ca fiecare operațiune de difuzare să fie atomică și auto-conținută. comparare(a, b) ar trebui să funcționeze, fără a cere utilizatorului să gestioneze instanțele serverului. Obiectivul de proiectare a fost clar: performanță nativă cu simplitatea unui apel de funcție. Învățarea de la Rust-Based JavaScript Tooling Răspunsul a venit din studierea modului în care alte instrumente JavaScript care rulează pe Rust se ocupă de această problemă. (linter/formatter) utilizează o arhitectură deosebit de curată: biomasă JavaScript API → N-API binding (.node file) → Rust core library
 Înțelegerea cheie este — ABI stabilă a Node.js pentru addon-uri native. În loc să dea naștere unui proces copil, codul Rust compilează într-un o bibliotecă partajată care se încarcă direct în procesul Node.js. Apelurile de funcție de la JavaScript la Rust devin apeluri directe de indicator de funcție. N-API .node Binariile specifice platformei sunt publicate ca pachete separate npm cu şi câmpuri : os cpu {
    "name": "@blazediff/bin-darwin-arm64",
    "os": ["darwin"],
    "cpu": ["arm64"],
    "files": ["blazediff", "blazediff.node"]
}
 Pachetul principal enumeră aceste : 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 instalează doar pachetul care corespunde platformei curente. fără scripturi postinstall. fără compilare. Arhitectura finală: Rust + N-API Arhitectura finală a lui BlazeDiff utilizează o abordare nivelată. Legarea N-API este calea rapidă. 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
 Legarea N-API este definită cu 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),
    })
}
 Pe partea JavaScript, legătura se încarcă lent și cachează rezultatul: 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;
}
 Configurația Cargo compilează aceeași crate ca atât un binar independent, cât și un cdylib (bibliotecă partajată pentru N-API): [lib]
name = "blazediff"
crate-type = ["lib", "cdylib"]

[features]
default = []
napi = ["dep:napi", "dep:napi-derive"]
 O bază de cod, două ținte de distribuție: un binar CLI și un modul nativ Node.js. Aceleași optimizări SIMD, același algoritm bazat pe blocuri, același lucru, doar un punct de intrare diferit. Lecții învățate Algoritmii înainte de limbi. Designul bazat pe blocuri a produs o accelerare de 72-88% în JavaScript pur, înainte ca orice Rust să fie scris. Alegerea algoritmului potrivit contează mai mult decât alegerea limbii potrivite. Dacă aș fi mers direct la Rust cu o abordare pixel-by-pixel, aș avea un scaner pixel rapid în loc de o imagine rapidă diferă. JavaScript are un plafon dur pentru munca numerica. Odată ce algoritmul a fost optimizat, timpul de execuție al JavaScript-ului – pauzele GC, încălzirea JIT, lipsa SIMD, lanțurile de căutare a proprietății – a devenit costul dominant. Pentru buclele numerice strânse peste buffer-urile mari, nici o cantitate de micro-optimizare nu poate depăși suprafața V8. Arhitectura procesului contează la fel de mult ca și designul algoritmului. Saltul de la Deciziile arhitecturale – modul în care invocați codul, modul în care transferați datele, modul în care gestionați ciclurile de viață ale proceselor – se compun cu fiecare apel. spawn(binary) N-API este un pod subevaluat. N-API oferă un ABI stabil în toate versiunile Node.js, ambalarea specifică platformei curate prin intermediul Este aceeași abordare utilizată de Biome, SWC și alte instrumente JavaScript de înaltă performanță. Dacă construiți o bibliotecă JavaScript critică pentru performanță și JavaScript însuși este punctul de blocare, N-API + Rust este o cale dovedită. optionalDependencies Benchmarcezi totul, nu ai încredere în nimic. Fiecare optimizare a fost validată cu benchmarks care rulează pe hardware consistent. Ruta WASM a fost explorată și abandonată (am încercat de fapt atât Rust WASM, cât și AssemblyScript – ambele au fost mai lente decât cele native pentru această sarcină de lucru). JavaScript rămâne unul dintre cele mai bune ecosisteme pentru instrumentele de dezvoltare: povestea managerului de pachete, integrarea cadrului de testare și amploarea comunității. Navele BlazeDiff ca un singur Sub capac, există 2.000 de linii de pixeli de procesare Rust optimizați pentru SIMD printr-un algoritm de blocare cu două trepte. . npm install compare(a, b) Acesta este obiectivul: performanța invizibilă. Utilizatorul nu ar trebui să știe sau să se îngrijoreze că Rust există.

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

Read My Stories

Acest audio este produs în limba originală a poveștii!

Depășirea limitelor performanței JavaScript cu Rust și N-API: Construirea unui instrument de difuzare a imaginilor mai rapid

About Author

COMENTARII

Etichete suspendate

ACEST ARTICOL A FOST PREZENTAT IN

Related Stories

Intel Stuns Employees By Cutting Free Office Fruit (And Staff)

The TechBeat: Apple Customers Return Vision Pro By The Droves (2/26/2024)

The TechBeat: Digital Transformation Success Stories in Mezzanine Lending (3/3/2024)

The TechBeat: Digital Transformation Success Stories in Mezzanine Lending (3/1/2024)

Intel Stuns Employees By Cutting Free Office Fruit (And Staff)

The TechBeat: Apple Customers Return Vision Pro By The Droves (2/26/2024)

The TechBeat: Digital Transformation Success Stories in Mezzanine Lending (3/3/2024)

The TechBeat: Digital Transformation Success Stories in Mezzanine Lending (3/1/2024)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps