Battre les limites de performance de JavaScript avec Rust et N-API: Construire un outil de diffusion d'images plus rapide

Le moment JavaScript a atteint son plafond de performance Test de régression visuelle est l'un de ces problèmes qui semble simple jusqu'à ce que vous l'échellez réellement. Prenez une capture d'écran avant votre changement, prenez-en une après, et diffusez-les. L’écosystème JavaScript dispose d’outils solides pour cela. est la norme – petite, assez rapide pour la plupart des cas, zéro dépendance. C’est une bibliothèque bien écrite. Mais « assez vite » commence à craquer lorsque vos captures d’écran sont en résolution 2K/4K, lorsque vous effectuez des comparaisons de lots sur des centaines de pages, et lorsque chaque milliseconde dans CI coûte un centime. pixelmatch Je voulais construire quelque chose de plus efficace. Conception de l'algorithme BlazeDiff Ma première idée était de diviser l'image en blocs et de sauter les régions inchangées complètement.La plupart des captures d'écran de l'interface utilisateur entre les cours sont 95% + identiques.Pourquoi scanner 18 millions de pixels pour un changement de couleur de bouton? À première vue, cela semble impossible. Vous ne pouvez pas savoir si un bloc a changé sans toucher ses pixels. Mais la plupart des algorithmes de diffusion d'image utilisent déjà un contrôle de niveau de byte bon marché avant d'effectuer des comparaisons perceptuelles coûteuses. L'idée était de diviser ces étapes en deux passes distinctes. Dans le pass froid, touchez chaque pixel mais faites seulement le contrôle bon marché, marquant les blocs comme changés ou inchangés. Dans le pass chaud, exécutez le travail coûteux uniquement sur les blocs marqués. Mais le travail coûteux ne fonctionne que sur les 1-5% des blocs qui diffèrent réellement. : L’architecture à deux passes Pass froid : scannez chaque bloc en utilisant une comparaison de niveau de byte bon marché. Si un pixel dans un bloc diffère, marquez-le comme modifié et poursuivez. Pass chaud : n’iterez que sur les blocs modifiés. Exécutez le pipeline perceptible complet : calcul du delta de couleur YIQ, détection du voisinage anti-aliasing, rendu de la sortie de couleur diff/AA. C’est le travail coûteux, et il ne touche qu’une petite fraction de l’image qui a réellement changé. Les dimensions des blocs avec les dimensions de l'image : 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 petites images obtiennent 8×8 blocs. Une capture d'écran 4K obtient 128×128 blocs. La formule assure que les blocs sont toujours des pouvoirs de deux (cache-line amical) et que la granularité échelle avec la surface de l'image. Pour une image de 5600×3200 avec un petit changement d'interface utilisateur, vous pourriez avoir 2000 blocs au total, mais seulement 15 contiennent des différences. Le hot pass, qui effectue les calculs coûteux, couvre moins de 1% de l'image. Les 99% restants obtiennent un remplissage à l'échelle grise rapide et continuent. Quand rien ne change, le cold pass rejette immédiatement chaque bloc. Implémentation de l’application JavaScript La première version de La conception basée sur des blocs a donné des accélérations significatives par rapport à la numérisation linéaire de pixelmatch, mais JavaScript lui-même est devenu la prochaine barrière. Bleué J’ai passé par plusieurs étapes d’optimisation : . 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 mise en œuvre de JavaScript a été 1,5 fois plus rapide que le pixelmatch en moyenne et jusqu'à 88% plus rapide sur des images identiques. 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% Images en 4K (diverses) 302 29 ans 211 92 millions 29,9 % de Imagerie 4K (identique) 19 18 ms 2,39 ms 87,5 % de La page complète (diverse) 331 94 ms 92.7 millions de dollars 72,1 % de Page complète (identique) 63.18 millions de 7,68 millions 87,8 % de L'optimisation basée sur des blocs fonctionnait clairement.Mais 211ms pour un seul diff 4K est encore lent lorsque vous exécutez des centaines d'entre eux.Et à ce stade, l'algorithme lui-même a été optimisé. Découvrir le plafond : comparer contre l'odiff En faisant du benchmarking, j’ai découvert — un outil de diffusion d'image écrit en Zig avec des liens OCaml. Il était constamment plus rapide que ma mise en œuvre JavaScript. Odiff Ce n’est pas surprenant, le code natif a des avantages fondamentaux : Accès direct à la mémoire. Aucune pause du collecteur de déchets. Aucun réchauffement de la compilation JIT. Le code fonctionne exactement comme compilé. JavaScript n'a pas d'accès direct aux éléments intrinsèques de SIMD tels que SSE4.1, AVX2 ou NEON. WebAssembly expose SIMD, mais il ajoute encore une surcharge par rapport au code natif pour les charges de travail comme celle-ci. Pas de V8 runtime, pas de boucle d'événements, pas de chaînes de recherche de propriétés. La réalité est claire : une fois l’algorithme optimisé, le langage et le temps de fonctionnement deviennent le facteur limitant. Utiliser l'algorithme pour se reposer La décision de porter à Rust est tombée sur plusieurs facteurs : Performances prévisibles. Pas de GC, pas de réchauffement JIT, pas de surcroît caché. Ce que vous écrivez est ce qui fonctionne. Principaux systèmes intrinsèques pour SSE4.1, AVX2/FMA, AVX-512 et NEON. Sécurité de la mémoire. Les blocs non sécurisés sont explicites et contenues. Le reste du code reçoit une vérification à vie et un prêt gratuit. Écosystème. napi-rs pour les liens Node.js, rayon pour le parallélisme, histoire de compilation croisée solide. Le port Rust suit la même architecture à deux passes. Voici le noyau du passage froid (la partie qui identifie les blocs qui ont changé): // 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'accélération SIMD est l'endroit où les choses deviennent intéressantes. Le calcul delta de couleur YIQ (conversion des différences RGB en différences perceptuelles) est la boucle intérieure la plus chaude. // 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 } Sur x86_64, la même logique s'exécute que SSE4.1 (4 pixels) ou AVX2+FMA (8 pixels), sélectionné au moment de l'exécution. La détection de fonctionnalités se produit une fois par diff, et le chemin SIMD le plus rapide disponible est utilisé pour l'ensemble de l'opération. Le port Rust initial correspondait aux performances du niveau Odiff.Le même algorithme, un langage différent, et soudain le temps d'exécution a disparu. Optimisation passe: rendre la rouille significativement plus rapide Matching odiff était la ligne de départ. Plusieurs tours d'optimisation ont poussé BlazeDiff bien au-delà. 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 { 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 Les résultats contre Odiff (y compris l’image complète I/O : décode, diff, encode) : 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) 119092 millions de dollars 293 86 millions de dollars 75.3% 4K / 2 1530.21 millions de dollars 363,5 millions de 76.2% 4K / 3 1835.47 ms par jour 389 à 67 ms 78.8% Page complète / 1 53520 millions 472.99 millions de dollars 54.3% Page complète / 2 89.79 millions de 26390 millions 55.9% 3 à 4 fois plus rapide sur les images 4K. La combinaison de la sortie précoce basée sur des blocs, de la vectorisation SIMD, de l'I/O parallèle et de l'optimisation agressive du compilateur s'ajoute. Le problème de l'intégration: Getting Rust in JavaScript Avoir un Rust binaire rapide est génial.Mais les utilisateurs cibles sont les développeurs JavaScript qui écrivent des tests visuels avec Playwright, Cypress ou Vitest. Non pas . npm install cargo install La première approche était évidente : Node.js → spawn binary → run diff → return result Envelopper le binaire Rust dans un paquet Node.js, le faire naître comme un processus enfant, et analyser la sortie JSON: try { await execFileAsync(binaryPath, args); return { match: true }; } catch (err) { // Parse exit codes: 0=identical, 1=pixel-diff, 2=error } Cela fonctionne. Il est simple, portable, et le binaire gère tout le lifting lourd. Mais dans un pipeline CI diffusant 500 captures d'écran, vous engendrez 500 processus. La création de processus n'est pas gratuite. Fork, exec, mapping de mémoire, chargement de bibliothèque partagé. L'overhead par spawn est petit, mais il s'ajoute. Les critères de référence ont montré qu'il mangeait 30-40% du temps total sur de petites images où la diffusion réelle prend <5ms. Pourquoi pas un serveur persistant ? Odiff résout ce problème en exécutant un processus de serveur persistant. Vous le démarrez une fois, envoyez des demandes diff sur un socket, et il les traite sans l'excès de spawn. J'ai considéré cette approche et je l'ai rejetée.Les compromis ne correspondaient pas au cas d'utilisation: Un serveur signifie gestion du cycle de vie : commencer avant les tests, arrêter après, gérer les accidents et les ports. Les fuites de mémoire deviennent un problème (je suis en fait entré dans cela plus tard avec mimalloc). Intégration CI. Les environnements CI sont éphémères. L'ajout d'un daemon serveur complique les images Docker, les workflows d'actions GitHub et le débogage. Je voulais que chaque opération diff soit atomique et autonome. comparer(a, b) devrait simplement fonctionner, sans que l'utilisateur soit tenu de gérer les instances de serveur. L’objectif de conception était clair : des performances natives avec la simplicité d’un appel de fonction. Apprendre avec Rust-Based JavaScript Tooling La réponse est venue de l’étude de la façon dont d’autres outils JavaScript alimentés par Rust traitent ce problème. (le linter/formatter) utilise une architecture particulièrement propre : biomasse JavaScript API → N-API binding (.node file) → Rust core library Le point de vue clé est — ABI stable de Node.js pour les addons natifs. Au lieu de donner naissance à un processus d'enfant, le code Rust compile à un une bibliothèque partagée qui se charge directement dans le processus Node.js. Les appels de fonctions de JavaScript à Rust deviennent des appels directs de pointeurs de fonctions. N-API .node La stratégie d'emballage est tout aussi importante. Les binaires spécifiques à la plate-forme sont publiés sous forme de paquets npm séparés avec et Les champs : os cpu { "name": "@blazediff/bin-darwin-arm64", "os": ["darwin"], "cpu": ["arm64"], "files": ["blazediff", "blazediff.node"] } Les principaux paquets énumèrent ces : 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 installe uniquement le package correspondant à la plate-forme actuelle. Aucun script postinstall. Aucune compilation. Architecture finale : Rust + N-API L'architecture finale de BlazeDiff utilise une approche de niveau. La liaison N-API est le chemin rapide. 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 Le lien N-API est défini par napi-rs : #[napi] pub fn compare( base_path: String, compare_path: String, diff_output: Option , options: Option , ) -> Result { // 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), }) } Sur le côté JavaScript, le lien charge lentement et cache le résultat : 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 configuration Cargo compile la même grille qu'une binaire indépendante et une cdylib (bibliothèque partagée pour N-API): [lib] name = "blazediff" crate-type = ["lib", "cdylib"] [features] default = [] napi = ["dep:napi", "dep:napi-derive"] Une base de codes, deux cibles de distribution: un CLI binaire et un module natif Node.js. Les mêmes optimisations SIMD, le même algorithme basé sur des blocs, tout le même, juste un point d'entrée différent. Les leçons apprises Les algorithmes avant les langues. La conception basée sur des blocs a produit des accélérations de 72 à 88% en JavaScript pur, avant qu'aucun Rust ne soit écrit.Le choix de l'algorithme approprié importe plus que le choix de la bonne langue.Si j'étais allé directement à Rust avec une approche pixel-by-pixel, j'aurais un scanner pixel rapide au lieu d'une image rapide différente. JavaScript a un plafond dur pour le travail numérique. Une fois que l’algorithme a été optimisé, le temps d’exécution supérieur de JavaScript – les pauses GC, le réchauffement de JIT, le manque de SIMD, les chaînes de recherche de propriétés – est devenu le coût dominant. Pour les boucles numériques serrées sur de grands tampons, aucune quantité de micro-optimisation ne peut surmonter le temps supérieur de V8. Ce n’est pas une critique de JavaScript. L’architecture de processus est aussi importante que la conception d’algorithmes. Le saut de Les décisions d'architecture - comment vous invoquez le code, comment vous transférez les données, comment vous gérez les cycles de vie des processus - se combinent avec chaque appel. Lorsque vous diffusez 500 images, la différence entre un appel de fonction et un processus est la différence entre les secondes et les minutes. spawn(binary) N-API est un pont sous-évalué. N-API fournit un ABI stable dans toutes les versions de Node.js, un emballage propre spécifique à la plate-forme via C'est la même approche utilisée par Biome, SWC et d'autres outils JavaScript haute performance. Si vous construisez une bibliothèque JavaScript critique pour la performance et que JavaScript lui-même est la barrière, N-API + Rust est un chemin éprouvé. optionalDependencies Benchmark tout, ne croyez rien. Chaque optimisation a été validée avec des critères de référence fonctionnant sur un matériel cohérent. L'itinéraire WASM a été exploré et abandonné (j'ai effectivement essayé à la fois Rust WASM et AssemblyScript - les deux étaient plus lents que natives pour cette charge de travail). La formule de taille de bloc a été ajustée empiriquement sur les tailles d'image de 100×100 à 5600×3200. JavaScript reste l’un des meilleurs écosystèmes pour l’outilage des développeurs : l’histoire du gestionnaire de paquets, l’intégration du framework de test et la largeur de la communauté.Mais parfois le chemin le plus rapide est de laisser le code natif faire le lourd lifting tandis que JavaScript reste l’interface que les développeurs aiment. BlazeDiff navires comme un seul Sous le capot, il y a 2000 lignes de pixels de traitement Rust optimisés pour SIMD à travers un algorithme de blocs à deux passes. . npm install compare(a, b) C’est l’objectif : des performances invisibles.L’utilisateur ne devrait pas avoir à savoir ou à se soucier que Rust existe.