El moment en què JavaScript va colpejar el seu sostre de rendiment El test de regressió visual és un d'aquells problemes que sona senzill fins que realment l'escalfeu. Pren una captura de pantalla abans del teu canvi, pren-ne una després i difondre'ls. Si no s'ajusten, alguna cosa s'ha trencat. L'ecosistema de JavaScript disposa d'eines sòlides per a això. és l'estàndard - petit, prou ràpid per a la majoria dels casos, zero dependències. És una biblioteca ben escrita. Però "molt ràpid" comença a esclatar quan les teves captures de pantalla són de resolució 2K/4K, quan estàs executant comparacions de lots a través de centenars de pàgines, i quan cada mil·lisegon de CI costa un cèntim. Pixelmatch Volia fer alguna cosa més eficient. Disseny de l'algoritme BlazeDiff La meva primera idea va ser dividir la imatge en blocs i saltar les regions sense canviar completament. La majoria de les captures de pantalla de la interfície d'usuari entre les execucions són 95% + idèntiques. A primera vista, això sembla impossible.No es pot saber si un bloc ha canviat sense tocar els seus píxels. Però la majoria dels algoritmes de difusió d'imatges ja utilitzen un control de nivell de byte barat abans d'executar comparacions perceptives costoses. La idea era dividir aquestes etapes en dues passes separades. En el pas fred, toqueu cada píxel però només feu el control barat, marcant els blocs com canvis o sense canvis. En el pas calent, executeu el treball costós només en blocs amb bandera. Però el treball costós només s'executa en l'1-5% dels blocs que realment difereixen. : Arquitectura de dos passos 
 
 
 Passatge fred: escaneja cada bloc utilitzant una comparació de nivell de byte barat. Si qualsevol píxel en un bloc difereix, marqui-lo com a canviat i seguir endavant. Hot Pass: Itera només sobre els blocs canviats. Executa el tub perceptual complet: càlcul del delta de color YIQ, detecció de veïns antialiasing, rendiment de sortida de color diff / AA. Això és el treball costós, i només toca una petita fracció de la imatge que realment ha canviat. Escales de mida de blocs amb dimensions d'imatge: 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)
}
 Les imatges petites obtenen 8×8 blocs. Una captura de pantalla 4K obté 128×128 blocs. La fórmula assegura que els blocs són sempre poders de dos (caxellera amigable) i que la granularitat escala amb l'àrea de la imatge. Per a una imatge de 5600×3200 amb un petit canvi d'interfície d'usuari, podries tenir 2.000 blocs en total, però només 15 contenen diferències. El pas calent, que realitza els càlculs cars, cobreix menys de l'1% de la imatge. El 99% restant rep un emplenament ràpid a escala de gris i continua. Quan no hi ha res canviat, el pas fred rebutja immediatament cada bloc. Introducció a la implementació de JavaScript La primera versió de El disseny basat en blocs va donar una acceleració significativa sobre l'escaneig lineal de pixelmatch, però JavaScript es va convertir en el següent obstacle. blaugrana He passat per diversos passos d'optimització: 
 
 
 
 
 
 
 . 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 La implementació de JavaScript va acabar sent 1,5 vegades més ràpida que el pixelmatch de mitjana i fins a un 88% més ràpida en imatges idèntiques. 
 
 
 
 
 
 
 
 
 
 
 
 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% Imatge en 4K (diferent) 302.29 Mèxic 211.92 Mèxic El 29,9% Imatge en 4K (Ideal) 19.18 milions 2.39 milions El 87,5% Pàgina completa (diferent) 331.94 ms 92.7 Mèxic El 72,1% Pàgina completa (Idioma) 63.18 Mèxic 7,68 Mèxic El 87,8% L'optimització basada en blocs estava clarament funcionant. però 211ms per a una sola dif 4K encara és lent quan s'executen centenars d'ells. Descobrint el sostre: comparant contra l'odiff En fer el benchmarking, hem descobert — una eina de difusió d'imatges escrita en Zig amb enllaços OCaml. Va ser constantment més ràpida que la meva implementació de JavaScript. Odif Això no va ser sorprenent. El codi natiu té avantatges fonamentals: 
 
 
 
 Accés directe a la memòria. No hi ha pauses del col·lector d'escombraries. No hi ha escalfament de la compilació JIT. El codi s'executa exactament com es va compilar. JavaScript no té accés directe a les parts intrínseques de SIMD com SSE4.1, AVX2 o NEON. WebAssembly exposa SIMD, però encara afegeix sobrecàrregues en comparació amb el codi natiu per a càrregues de treball com aquesta. Sense temps d'execució V8, sense cicle d'esdeveniments, sense cadenes de cerca de propietats. La realitat és clara: una vegada optimitzat l'algorisme, el llenguatge i el temps d'execució es converteixen en el factor limitant. Portar l'algoritme a Rust La decisió de portar a Rust es va reduir a diversos factors: 
 
 
 
 
 Previsible rendiment. No GC, no JIT escalfament, no ocult sobrecap. El que escrius és el que funciona. Primera classe intrínsecs per a SSE4.1, AVX2/FMA, AVX-512 i NEON. Seguretat de la memòria. Els blocs insegurs són explícits i continguts. La resta del codi rep vida i comprovació de préstec gratuïta. Ecosistema. napi-rs per a vinculacions de Node.js, rayon per al paral·lelisme, història de compilació creuada sòlida. El port Rust segueix la mateixa arquitectura de dos passos.Aquí hi ha el nucli del pas fred (la part que identifica quins blocs han canviat): // 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,
                );
            }
        }
    }
}
 L'acceleració SIMD és on les coses es tornen interessants. La computació del delta del color YIQ (conversió de les diferències RGB en diferències perceptuals) és el bucle interior més calent. // 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
}
 En x86_64, la mateixa lògica s'executa com SSE4.1 (4 píxels) o AVX2 + FMA (8 píxels), seleccionats en el moment de execució. La detecció de característiques es produeix una vegada per dif, i s'utilitza el camí SIMD més ràpid disponible per a tota l'operació. El port inicial de Rust va coincidir amb el rendiment a nivell d'odiff. El mateix algorisme, un llenguatge diferent i, de sobte, el temps d'execució va desaparèixer. Passos d'optimització: fer que la rugositat sigui significativament més ràpida Matching odiff va ser la línia de base. Diverses rondes d'optimització van empènyer BlazeDiff molt més enllà d'això. 
 
 
 
 
 
 
 
  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
 Els resultats contra l'odiff (incloent la imatge completa I/O: decodificació, dif, codificació): 
 
 
 
 
 
 
 
 
 
 
 
 
 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 x 3200) 11909 milions 293.86 Mèxic 75.3% 4K / 2 1530.21 milions d'euros 363.50 milions 76.2% 4K / 3 1835.47 ms 389.67 milions 78.8% Pàgina completa / 1 105.20 Mèxic 472.99 Mèxic 54.3% Pàgina completa / 2 89.79 milions 26390 milions 55.9% 3-4 vegades més ràpid en imatges 4K. La combinació de sortida primerenca basada en blocs, vectorització SIMD, I/O paral·lel i optimització compiladora agressiva s'ajusta. El problema d'integració: Getting Rust en JavaScript Tenir un ràpid Rust binari és genial, però els usuaris objectius són desenvolupadors de JavaScript que escriuen proves visuals amb Playwright, Cypress o Vitest. No no . npm install cargo install La primera és l’evident: Node.js → spawn binary → run diff → return result
 Embolicem el binari de Rust en un paquet Node.js, el formem com un procés infantil i analitzem la sortida de JSON: try {
  await execFileAsync(binaryPath, args);
  return { match: true };
} catch (err) {
  // Parse exit codes: 0=identical, 1=pixel-diff, 2=error
}
 Això funciona. És simple, portàtil, i el binari gestiona tot el pesat aixecament. Però en una canonada de CI que difereix de 500 captures de pantalla, estàs engendrant 500 processos. La creació del procés no és gratuïta. Fork, exec, mapping de memòria, càrrega de biblioteca compartida. La sobrecàrrega per esponja és petita, però s'afegeix. Els indicadors de referència van mostrar que estava menjant el 30-40% del temps total en imatges petites on la difusió real pren <5ms. Per què no un servidor diferent? Odiff soluciona aquest problema executant un procés de servidor persistent. L'inicia una vegada, envia sol·licituds dif a través d'un socket, i les gestiona sense el capgirament. Vaig considerar aquest enfocament i el vaig rebutjar.Els compromisos no van encaixar en el cas d'ús: 
 
 
 
 
 Un servidor significa gestió del cicle de vida: iniciar-lo abans de les proves, aturar-lo després, gestionar els accidents i gestionar ports. Statefulness. Un procés de llarga durada acumula estat. les fuites de memòria es converteixen en un problema (de fet vaig entrar en això més tard amb mimalloc). La integració de CI. Els entorns de CI són efímers. L'addició d'un daemon del servidor complica les imatges de Docker, els fluxos de treball d'accions de GitHub i la depuració. Volia que cada operació de difusió fos atòmica i autònom. comparar(a, b) només hauria de funcionar, sense necessitar que l'usuari gestioni instàncies de servidor. L'objectiu del disseny era clar: rendiment natiu amb la simplicitat d'una trucada de funció. Aprenentatge a partir d'eines de JavaScript basades en Rust La resposta prové de l'estudi de com altres eines de JavaScript amb Rust gestionen aquest problema. (el linter/formatter) utilitza una arquitectura particularment neta: Biomèdia JavaScript API → N-API binding (.node file) → Rust core library
 La clau de la comprensió és — ABI estable de Node.js per a addons natius. En comptes d'engendrar un procés infantil, el codi Rust compila a un Una biblioteca compartida que carrega directament al procés Node.js. Les trucades de funcions de JavaScript a Rust es converteixen en trucades directes de punter de funció. N-API .node L'estratègia d'embalatge és igualment important. Els binaris específics de la plataforma es publiquen com a paquets npm separats amb i Els camps: os cpu {
    "name": "@blazediff/bin-darwin-arm64",
    "os": ["darwin"],
    "cpu": ["arm64"],
    "files": ["blazediff", "blazediff.node"]
}
 El paquet principal enumera aquestes com : 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 només instal·la el paquet que coincideix amb la plataforma actual. No hi ha scripts de postinstal·lació. No hi ha compilació. Només un binari preconstruït. Arquitectura final: Rust + N-API L'arquitectura final de BlazeDiff utilitza un enfocament de nivell. La vinculació N-API és el camí ràpid. 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
 La vinculació N-API es defineix amb 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),
    })
}
 Al costat de JavaScript, el vincle carrega lentament i cache el resultat: 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;
}
 La configuració de càrrega compila la mateixa grua com tant un binari autònom com un cdylib (biblioteca compartida per a N-API): [lib]
name = "blazediff"
crate-type = ["lib", "cdylib"]

[features]
default = []
napi = ["dep:napi", "dep:napi-derive"]
 Una base de codi, dos objectius de distribució: un binari CLI i un mòdul natiu Node.js. Les mateixes optimitzacions de SIMD, el mateix algoritme basat en blocs, tot el mateix, només un punt d'entrada diferent. Les lliçons aprenent Algoritmes abans de llengües. El disseny basat en blocs va produir una acceleració del 72-88% en JavaScript pur, abans que es escrigués qualsevol Rust. triar l'algorisme correcte és més important que triar el llenguatge correcte. Si hagués anat directament a Rust amb un enfocament de píxel per píxel, tindria un escàner de píxels ràpids en comptes d'una imatge ràpida diferent. JavaScript té un sostre dur per al treball numèric. Una vegada que l'algorisme va ser optimitzat, el temps d'execució superior de JavaScript - pauses de GC, escalfament de JIT, manca de SIMD, cadenes de cerca de propietats - es va convertir en el cost dominant. Per a buffs numèrics estrets sobre buffers grans, cap quantitat de micro-optimització pot superar el V8. L'arquitectura de processos és tan important com el disseny d'algoritmes. El salt de a N-API va ser una millora més gran que alguns canvis algorítmics. Decisions d'arquitectura -com s'invoquen el codi, com es transfereixen les dades, com es gestionen els cicles de vida del procés - es combinen amb cada trucada. spawn(binary) El N-API és un pont subestimat. N-API proporciona un ABI estable a través de les versions de Node.js, amb paquets específics per a plataformes netes És el mateix enfocament utilitzat per Biome, SWC i altres eines de JavaScript d'alt rendiment. Si estàs construint una biblioteca de JavaScript crítica per al rendiment i el JavaScript és el botó, N-API + Rust és un camí provat. optionalDependencies Benchmark tot, no confiar en res. Totes les optimitzacions es van validar amb criteris de referència que funcionaven en maquinari coherent. La ruta WASM va ser explorada i abandonada (en realitat vaig provar tant Rust WASM com AssemblyScript - tots dos eren més lents que nadius per a aquesta càrrega de treball). La fórmula de mida de bloc es va ajustar empíricament entre les mides d'imatge de 100×100 a 5600×3200. JavaScript segueix sent un dels millors ecosistemes per a l'eina de desenvolupament: la història del gestor de paquets, la integració del marc de prova i l'amplària de la comunitat. BlazeDiff vaixells com un sol Sota el capó, hi ha 2.000 línies de píxels de processament Rust optimitzats per SIMD a través d'un algorisme de blocs de dos passos. . npm install compare(a, b) Aquest és l'objectiu: el rendiment invisible.L'usuari no hauria de saber ni preocupar-se que Rust existeix.

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

Read My Stories

Aquest àudio és produït a l'idioma original de la història!

Batre els límits de rendiment de JavaScript amb Rust i N-API: Construir una eina de difusió d'imatges més ràpida

About Author

COMENTARIS

Etiquetes penjant

AQUEST ARTICLE VA SER PRESENTAT A

Related Stories

Startups of The Year: Meet the Education Industry

The Jewel Robbery at the Grand Metropolitan

What Are Writers' Biggest Struggles in 2025?

On Taxes

Startups of The Year: Meet the Education Industry

The Jewel Robbery at the Grand Metropolitan

What Are Writers' Biggest Struggles in 2025?

On Taxes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps