The Moment JavaScript pogodio svoj gornji prag performansi Vizuelno regresijsko testiranje je jedan od onih problema koji zvuči jednostavno dok ga zapravo ne skališete. Uzimajte screenshot prije svoje promene, uzmite jedan nakon toga i difuzirajte ih. Ako se ne podudaraju, nešto se slomilo. Svaki CI cevovod koji radi vizuelno testiranje radi hiljade puta dnevno. JavaScript ekosustav ima čvrste alate za to. je standard – mali, dovoljno brz za većinu slučajeva, nula ovisnosti. To je dobro napisana biblioteka. Ali „dovoljno brzo“ počinje da pukne kada su vaši screenshotovi 2K/4K rezolucije, kada radite usporedbe partija na stotinama stranica, i kada svaka milisekunda u CI košta novčić. Pikseli Htela sam izgraditi nešto efikasnije. Dizajn BlazeDiff algoritma Moja prva ideja bila je da podelim sliku na blokove i preskočim nepromijenjene regije u potpunosti. Većina UI screenshotova između pokretanja je 95% + identična. Zašto skenirati 18 miliona piksela za promjenu boje dugmeta? Na prvi pogled, to zvuči nemoguće. Ne možete znati da li se blok promijenio bez dodirivanja njegovih piksela. Ali većina algoritama za diferencijaciju slika već koristi jeftinu provjeru na nivou bajta pre nego što pokrene skupe perceptivne poređenja. Uvid je bio da te faze podeli na dva odvojena prolaza. U hladnom prolazu dodirnite svaki piksel, ali samo napravite jeftinu provjeru, označavajući blokove kao promijenjene ili nepromijenjene. U vrućem prolazu, pokrenite skupi posao samo na označenim blokovima. I dalje skenirate svaki piksel jednom, ali skupi rad radi samo na 1-5% blokova koji se zapravo razlikuju. : Dvostruka arhitektura 
 
 
 Hladni prolaz: Skenirajte svaki blok pomoću jeftine usporedbe na nivou bajta. Ako se bilo koji piksel u bloku razlikuje, označite ga kao promenjen i nastavite dalje. Vrući prolaz: Iterirajte samo preko promijenjenih blokova. Pokrenite punu perceptivnu cevovodu: YIQ boja delta računanje, anti-aliasing detekcija susjedstva, diff / AA reprodukcija izlaza boja. Ovo je skup posao, i to samo dodiruje mali deo slike koja se zapravo promijenila. Blok veličine skale sa dimenzijama slike: 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)
}
 Male slike dobijaju 8×8 blokova. 4K screenshot dobija 128×128 blokova. Formula osigurava blokovi su uvek snage od dva (cache-line prijateljski) i da granularnost skala s površinom slike. Hladni prolaz je odakle dolazi većina ubrzanja. Za sliku od 5600×3200 sa malom promjenom UI-a, možda ćete imati ukupno 2.000 blokova, ali samo 15 sadrži razlike. Vrući prolaz, koji izvodi skupe izračune, pokriva manje od 1% slike. Preostalih 99% dobija brzo punjenje sive ljestvice i kreće dalje. Kada se ništa ne promeni, hladni prolaz odmah odbacuje svaki blok. Iteriranje na JavaScript implementaciji Prva verzija Dizajn zasnovan na blokovima dao je značajna ubrzanja u odnosu na linearno skeniranje pixelmatcha, ali sam JavaScript postao je sledeća bočna točka. Blažević Prošao sam kroz nekoliko optimizacijskih prolaza: 
 
 
 
 
 
 
 . 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 Implementacija JavaScript-a završila je 1,5 puta brže od pixelmatcha u prosjeku i do 88% brže na identičnim slikama. 
 
 
 
 
 
 
 
 
 
 
 
 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 slike (različite) 302.29ms za preduzetnike Preporučuje se 211.92ms Preduzetništvo 29,9 % 4K slika (Idealna) 18.8 miliona evra 2.9 miliona evra Uslovi korišćenja 87,5% Cijela stranica (različiti) Preporučeni broj: 331.94ms Brojke: 92,77 ms 72 odsto Cijela stranica (Idealna) 63.18 ms 7.8 miliona evra Uslovi korišćenja 87,8% Optimizovanje zasnovano na blokovima jasno je funkcionisalo. Ali 211ms za jedan 4K diff je još uvijek sporo kada pokrećete stotine njih. Otkrivanje plafona: Usporedba protiv odifa Dok sam benchmarking, otkrio sam — image diff alat napisan u Zig sa OCaml vezanja. To je bio dosljedno brži od moje JavaScript implementacije. Odić To nije iznenađujuće. izvorni kod ima osnovne prednosti: 
 
 
 
 Neposredni pristup memoriji. Bez pauza za sakupljanje smeća. Bez zagrijavanja kompilacije JIT. Koda radi tačno onako kako je kompilirana. SIMD upute. JavaScript nema direktan pristup SIMD intrinsicima kao što su SSE4.1, AVX2 ili NEON. WebAssembly otkriva SIMD, ali još uvek dodaje overhead u poređenju s nativnim kodom za radna opterećenja kao što je ovo. Niži runtime overhead. bez V8 runtime, bez događaja, bez lanaca za pretraživanje nekretnina. Stvarnost je jasna: jednom kada je algoritam optimizovan, jezik i runtime postaju ograničavajući faktor. Preuzimanje algoritma za odmor Odluka o pristaništu u Rust se svodi na nekoliko faktora: 
 
 
 
 
 Predvidive performanse. Bez GC, bez JIT zagrijavanja, bez skrivenog nadglavlja. Ono što pišete je ono što radi. Podrška za SIMD. prvoklasne intrinsike za SSE4.1, AVX2/FMA, AVX-512 i NEON. Bezbednost memorije. Nezaštićeni blokovi su eksplicitni i sadržani. Ostatak koda dobija doživotno i pozajmi provjeru besplatno. Ecosystem. napi-rs za Node.js vezivanje, rayon za paralelizam, solidnu priču križnog kompilacije. Rust port slijedi istu arhitekturu dva prolaza. Evo jezgra hladnog prolaza (deo koji identifikuje koje su blokove promijenili): // 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 ubrzanje je tamo gde stvari postaju zanimljive. YIQ boja delta računanje (konverzija RGB razlike u perceptualne razlike) je najtopliji unutrašnji krug. Evo jezgra NEON implementacije za ARM (obrada 4 piksela istovremeno): // 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, istu logiku radi kao SSE4.1 (4 piksela) ili AVX2+FMA (8 piksela), odabranog na runtime. Detekcija funkcija se događa jednom po dif, a najbrži raspoloživi SIMD put se koristi za čitavu operaciju. Početni Rust port odgovarao je performansi na razini odiff. isti algoritam, drugačiji jezik, i odjednom runtime overhead je nestao. Optimizacija prolazi: Stvaranje hrđa znatno brže Usklađivanje odiff bio je osnovna linija. Nekoliko krugova optimizacije gurnuo BlazeDiff daleko iza njega. 
 
 
 
 
 
 
 
  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
 Rezultati protiv odiff (uključujući punu sliku I/O: dekodiranje, diff, kodiranje): 
 
 
 
 
 
 
 
 
 
 
 
 
 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) 1190.92ms u toku dana 293.86ms za preglede 75.3% 4K i 2K 1530.21ms u Nemačkoj 363.50 miliona evra 76.2% 4K i 3K Uslovi korišćenja 1835.47ms 389.67ms u toku dana 78.8% Cijela stranica / 1 105.20 miliona evra 472.99ms za preduzetnike 54.3% Cijela stranica / 2 5989 miliona evra 263.90 miliona evra 55.9% 3-4x brže na 4K slikama. Kombinacija blok-based ranog izlaska, SIMD vektorizacije, paralelnog I/O i agresivne kompilera optimizacije dodaje se. Problem integracije: Getting Rust u JavaScript Imati brz Rust binarni je sjajan. ali ciljni korisnici su JavaScript programeri pišu vizualne testove sa Playwright, Cypress, ili Vitest. Ne ne . npm install cargo install Prvi pristup bio je očigledan: Node.js → spawn binary → run diff → return result
 Uključite Rust binary u Node.js paket, spawn ga kao proces deteta, i analizirati JSON izlaz: try {
  await execFileAsync(binaryPath, args);
  return { match: true };
} catch (err) {
  // Parse exit codes: 0=identical, 1=pixel-diff, 2=error
}
 To radi. To je jednostavno, prenosivo, a binarni rukuje svim teškim podizanjem. Ali u CI pipeline diffing 500 screenshots, vi rodite 500 procesa. Proces stvaranje nije besplatno. Fork, exec, memorije mapping, zajednička knjižnica utovara. Overhead po spawn je mali, ali to dodaje. Benchmarks pokazali da je jelo 30-40% od ukupnog vremena na malim slikama gde stvarni diff traje <5ms. Zašto ne postoji stalni diff server? Odiff rješava ovaj problem pokretanjem trajnog server procesa. Vi ga pokrenete jednom, šaljete diff zahteve preko prijenosa, a on ih rješava bez spawn overhead. Razmotrio sam ovaj pristup i odbio ga. kompromisi nisu odgovarali slučaju upotrebe: 
 
 
 
 
 Kompleksnost.Server znači upravljanje životnim ciklusom: pokrenite ga prije testiranja, zaustavite ga nakon toga, upravljajte nesrećama i upravljajte portovima. Statefulness. dugotrajni proces akumulira stanje. Memory lekovi postaju problem (Ja sam zapravo ušao u ovo kasnije sa mimalloc). CI integracija. CI okruženja su efemerna. Dodavanje server daemon komplicira Docker slike, GitHub akcije tokove posla i debugging. Želeo sam da svaka operacija dif bude atomska i samostalna. usporediti(a, b) samo treba da radi, bez zahtijevanja da korisnik upravlja instancama servera. Cilj dizajna bio je jasan: native performanse sa jednostavnošću funkcije poziva. Učenje iz Rust-Based JavaScript Tooling Odgovor je došao iz proučavanja kako drugi alat za JavaScript koji upravlja Rust-om rješavaju ovaj problem. (linter/formatter) koristi posebno čistu arhitekturu: Biomasa JavaScript API → N-API binding (.node file) → Rust core library
 Ključni uvid je — Node.js je stabilan ABI za native addons. Umjesto da rađa proces deteta, kod Rust kompilira na zajednička biblioteka koja se direktno učita u proces Node.js. Pozivi funkcija iz JavaScript-a na Rust postaju direktni pozivi na funkcije. Nema serializacije, nema IPC-a, nema procese. N-API .node Jednako je važna i strategija pakiranja.Binarije specifične za platformu objavljuju se kao zasebni npm paketi sa i Polja : os cpu {
    "name": "@blazediff/bin-darwin-arm64",
    "os": ["darwin"],
    "cpu": ["arm64"],
    "files": ["blazediff", "blazediff.node"]
}
 Glavni paketi navedeni su kao : 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 instalira samo paket koji odgovara trenutnoj platformi. Nema postinstalacijskih skripta. Nema kompilacije. Samo predgrađeni binarni. Konačna arhitektura: Rust + N-API BlazeDiffova konačna arhitektura koristi raznovrsni pristup. N-API vezivanje je brz put. 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 vezivanje je definisano 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 JavaScript strani, vezivanje lagano učitava i caches rezultat: 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;
}
 Konfiguracija Cargo kompilira istu rešetku kao i standalone binary i cdylib (zajednička biblioteka za N-API): [lib]
name = "blazediff"
crate-type = ["lib", "cdylib"]

[features]
default = []
napi = ["dep:napi", "dep:napi-derive"]
 Jedna kodna baza, dva distribucijska cilja: CLI binarni i Node.js nativni modul. Isti SIMD optimizacije, isti algoritam zasnovan na blokovima, isto sve, samo drugačija ulazna tačka. Lekcije naučene Algoritmi pre jezika. Dizajn zasnovan na blokovima proizvodi 72-88% ubrzanja u čistom JavaScript-u, prije nego što je bilo koji Rust napisan. Odabir pravog algoritma je važniji od odabira pravog jezika. JavaScript ima težak plafon za numerički rad. Nakon što je algoritam optimizovan, JavaScriptov runtime overhead – GC pauze, JIT zagrijavanje, nedostatak SIMD-a, lanci pretraživanja nekretnina – postao je dominantni trošak. Za uske numeričke krugove preko velikih bufera, nijedna količina mikro-optimizacije ne može nadvladati V8 overhead. Ovo nije kritika JavaScript-a. Procesna arhitektura je važna koliko i dizajn algoritma. Skok iz N-API je bilo veće poboljšanje od nekih algoritamskih promjena. Arhitektonske odluke – kako se poziva kod, kako se prenose podaci, kako se upravlja životnim ciklusima procesa – spojene su sa svakim pozivom. Kada se difuše 500 slika, razlika između poziva funkcije i spawn procesa je razlika između sekundi i minuta. spawn(binary) N-API je podcijenjen most. N-API pruža stabilan ABI u svim Node.js verzijama, čisti paket specifičan za platformu preko To je isti pristup koji koriste Biome, SWC i drugi visoke performanse JavaScript alata. Ako gradite performanse-kritičnu JavaScript biblioteku i sam JavaScript je bottleneck, N-API + Rust je dokazan put. optionalDependencies Benchmark sve, ne vjerujte ništa. Svaka optimizacija je validirana pomoću referentnih točaka koji se rade na dosljednom hardveru. WASM ruta je istražena i napuštena (istočno sam pokušao i Rust WASM i AssemblyScript – oba su bila sporija nego što je uobičajeno za ovo radno opterećenje). Formula veličine bloka je empirički prilagođena veličinama slika od 100×100 do 5600×3200. JavaScript ostaje jedan od najboljih ekosustava za alat za programere: priča o menadžeru paketa, integracija testiranja okvira i čista širina zajednice. BlazeDiff brodovi kao jedan Pod poklopcem, to je 2.000 linija Rust procesorskih piksela optimizovanih za SIMD kroz algoritam blokova sa dva prolaza. . npm install compare(a, b) To je cilj: nevidljivi performanse. korisnik ne bi trebao znati ili brinuti da Rust postoji.

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

Read My Stories

Ovaj audio je proizveden na originalnom jeziku priče!

Prevladavanje ograničenja performansi JavaScript-a sa Rust i N-API-jem: Izgradnja bržeg alata za razlikovanje slika

About Author

KOMENTARI

HANG TAGS

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps