การเอาชนะขีด จํากัด ประสิทธิภาพของ JavaScript ด้วย Rust และ N-API: สร้างเครื่องมือการกระจายภาพที่รวดเร็วขึ้น

The Moment JavaScript ระเบิดเพดานประสิทธิภาพของมัน การทดสอบการย้อนกลับทางวิสัยทัศน์เป็นหนึ่งในปัญหาที่ดูเรียบง่ายจนกว่าคุณจะปรับขนาดได้ ทําภาพหน้าจอก่อนการเปลี่ยนแปลงของคุณทําหนึ่งหลังจากนั้นและ diff พวกเขา หากพวกเขาไม่ตรงกับบางสิ่งบางอย่างแตก แต่ละท่อ CI ที่ทําการทดสอบทางวิสัยทัศน์ทํางานหลายพันครั้งต่อวัน ระบบนิเวศของ JavaScript มีเครื่องมือที่แข็งแกร่งสําหรับสิ่งนี้ เป็นมาตรฐาน - ขนาดเล็กที่รวดเร็วพอสําหรับกรณีส่วนใหญ่ไม่มีการพึ่งพา มันเป็นห้องสมุดที่เขียนได้ดี แต่ "เร็วพอ" จะเริ่มแตกเมื่อภาพหน้าจอของคุณมีความละเอียด 2K / 4K เมื่อคุณเรียกใช้การเปรียบเทียบชุดผ่านหลายร้อยหน้าและเมื่อแต่ละมิลลิสวินาทีใน CI ค่าใช้จ่ายหนึ่งเหรียญ พิกเซล ฉันต้องการสร้างสิ่งที่มีประสิทธิภาพมากขึ้น การออกแบบอัลกอริทึม BlazeDiff ความคิดครั้งแรกของฉันคือการแบ่งภาพลงในบล็อกและล้มเหลวพื้นที่ที่ไม่ได้เปลี่ยนแปลงอย่างสมบูรณ์ ภาพหน้าจอ UI ส่วนใหญ่ระหว่างการทํางานคือ 95% + เหมือนกัน ทําไมต้องสแกน 18 ล้านพิกเซลเพื่อเปลี่ยนสีปุ่ม? ที่มุมมองแรกนี้ดูเป็นไปไม่ได้ คุณไม่สามารถรู้ว่าบล็อกเปลี่ยนได้หรือไม่โดยไม่ต้องสัมผัสพิกเซล แต่อัลกอริทึมภาพ diff ส่วนใหญ่ใช้การตรวจสอบระดับ byte ราคาถูกก่อนที่จะเรียกใช้การเปรียบเทียบการรับรู้ที่มีราคาแพง ความเข้าใจคือการแบ่งขั้นตอนเหล่านี้เป็นสองขั้นตอนที่แยกต่างหาก ในช่วงเย็นสัมผัสทุกพิกเซล แต่ทําเพียงการตรวจสอบราคาไม่แพงทําเครื่องหมายบล็อกเป็นเปลี่ยนแปลงหรือไม่เปลี่ยนแปลง ในช่วงร้อนเรียกใช้งานที่แพงเฉพาะในบล็อกที่มีสัญลักษณ์ คุณยังสแกนทุกพิกเซลครั้งเดียว แต่การทํางานที่แพงใช้เวลาเพียง 1-5% ของบล็อกที่แตกต่างกันจริง ๆ : สองผ่านสถาปัตยกรรม ผ่านเย็น: สแกนบล็อกแต่ละบล็อกโดยใช้การเปรียบเทียบระดับบิตราคาถูก หากพิกเซลใด ๆ ในบล็อกแตกต่างกันให้ทําเครื่องหมายเป็นเปลี่ยนแปลงและดําเนินการต่อไป หากบล็อกมีความเหมือนกันอย่างสมบูรณ์ให้วาดผลลัพธ์ระดับสีเทาทันทีและลืมเกี่ยวกับมัน ร้อนผ่าน: อธิบายเฉพาะบนบล็อกที่เปลี่ยนแปลง ดําเนินการท่อการรับรู้เต็มรูปแบบ: การคํานวณ delta สี YIQ, การตรวจจับบริเวณใกล้เคียงป้องกันการหลอกลวง, การแสดงผลการส่งออกสี diff / AA นี่คืองานที่แพงและมันสัมผัสเพียงส่วนเล็ก ๆ ของภาพที่เปลี่ยนจริง ๆ ขนาดบล็อกมีขนาดภาพ: 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) } รูปภาพขนาดเล็กได้รับ 8 × 8 บล็อก ภาพหน้าจอ 4K ได้รับ 128 × 128 บล็อก สูตรที่ให้แน่ใจว่าบล็อกมีอํานาจของสอง (cache-line เพื่อน) และ granularity มีขนาดใหญ่กับพื้นที่ของภาพ การผ่านเย็นเป็นสถานที่ที่ส่วนใหญ่ของการเพิ่มความเร็วมาจาก สําหรับภาพ 5600 × 3200 กับการเปลี่ยนแปลง UI ขนาดเล็กคุณอาจมีบล็อก 2,000 รวม แต่เพียง 15 มีความแตกต่าง การผ่านร้อนซึ่งดําเนินการคํานวณราคาแพงครอบคลุมน้อยกว่า 1% ของภาพ 99% ที่เหลือได้รับการเติมสีเทาอย่างรวดเร็วและเคลื่อนย้ายไป เมื่อไม่มีอะไรเปลี่ยนแปลงการผ่านเย็นปฏิเสธบล็อกแต่ละบล็อกทันที Iterating บนการใช้งาน JavaScript เวอร์ชันแรกของ การออกแบบตามบล็อกช่วยเพิ่มความเร็วอย่างมีนัยสําคัญเมื่อเทียบกับการสแกนเชิงเส้นของ pixelmatch แต่ JavaScript ได้กลายเป็นขีดข่วนต่อไป แบล็กซ์ ฉันผ่านขั้นตอนการเพิ่มประสิทธิภาพหลายขั้นตอน: . 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 การประยุกต์ใช้ JavaScript ได้เร็วขึ้น 1.5 เท่ากว่า pixelmatch โดยเฉลี่ยและเร็วขึ้นถึง 88% บนรูปภาพที่เหมือนกัน หมายเลขจาก benchmarks บน M1 Max: 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 (แตกต่างกัน) 302.29 มม 211.92 มม 29.9 % รูปภาพ 4K (เหมือนกัน) 19.18 มม 2.39 มม 87.5% ของ หน้าที่เต็มรูปแบบ (แตกต่างกัน) 331.94 มม 92.77 มม 72.1% หน้าที่เต็ม (เหมือนกัน) 63.18 มม 7.68 มม 87.8% การเพิ่มประสิทธิภาพบนพื้นฐานบล็อกทํางานอย่างชัดเจน แต่ 211ms สําหรับ diff 4K เดียวยังคงช้าเมื่อคุณเรียกใช้หลายร้อยของพวกเขา และในขณะนี้อัลกอริทึมตัวเองได้รับการเพิ่มประสิทธิภาพ อัตราการทํางานของ JavaScript ยังคงเป็นขีดข่วน การค้นพบเพดาน: การเปรียบเทียบกับ Odiff ในขณะที่ benchmarking ฉันค้นพบ — เครื่องมือภาพ diff เขียนใน Zig กับ OCaml bindings มันเป็นอย่างสม่ําเสมอเร็วกว่าการใช้งาน JavaScript ของฉัน หยาบคาย สิ่งนี้ไม่น่าแปลกใจ รหัสเดิมมีข้อดีพื้นฐาน: การเข้าถึงหน่วยความจําโดยตรง ไม่มีการหยุดชะลอตัวเก็บฝุ่น ไม่มีการอุ่นการประกอบ JIT รหัสทํางานอย่างแม่นยําตามที่ประกอบ คําแนะนํา SIMD JavaScript ไม่ได้เข้าถึง SIMD intrinsics เช่น SSE4.1, AVX2 หรือ NEON WebAssembly เปิดเผย SIMD แต่ยังเพิ่ม overhead เมื่อเทียบกับรหัสพื้นฐานสําหรับโหลดทํางานเช่นนี้ ระยะเวลาการทํางานที่ต่ํากว่า ไม่ V8 ระยะเวลาการทํางานไม่มีวงจรเหตุการณ์ไม่มีโซ่การค้นหาทรัพย์สิน ความจริงที่ชัดเจน: เมื่ออัลกอริทึมได้รับการเพิ่มประสิทธิภาพแล้วภาษาและเวลาทํางานจะกลายเป็นปัจจัย จํากัด คุณไม่สามารถเพิ่มประสิทธิภาพมากกว่าพื้นฐานของ JavaScript แพทช์อัลกอริทึมเพื่อพักผ่อน การตัดสินใจที่จะพอร์ตไปยัง Rust ขึ้นอยู่กับปัจจัยหลายประการ: ประสิทธิภาพที่คาดการณ์ได้ ไม่มี GC ไม่มี JIT warmup ไม่มี overhead ที่ซ่อนอยู่ สิ่งที่คุณเขียนคือสิ่งที่ทํางาน การสนับสนุน SIMD หลักสําหรับ SSE4.1, AVX2/FMA, AVX-512 และ NEON ความปลอดภัยของหน่วยความจํา บล็อกที่ไม่ปลอดภัยจะชัดเจนและมีอยู่ ส่วนที่เหลือของรหัสจะได้รับการตรวจสอบตลอดชีวิตและให้เช่าฟรี Ecosystem. napi-rs สําหรับ Node.js bindings, rayon สําหรับ parallelism, solid cross-compilation story พอร์ต Rust สอดคล้องกับสถาปัตยกรรมสองผ่านเดียวกัน นี่คือหลักของพอร์ตเย็น (ส่วนที่ระบุบล็อกที่เปลี่ยน): // 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 เป็นสถานที่ที่สิ่งต่าง ๆ จะกลายเป็นที่น่าสนใจ การคํานวณ delta สี YIQ (การแปลงความแตกต่างของ RGB เป็นความแตกต่างในการรับรู้) เป็นวงกลมภายในที่ร้อนที่สุด นี่คือหลักของการใช้งาน NEON สําหรับ ARM (ประมวลผล 4 พิกเซลพร้อมกัน): // 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 } บน x86_64 โลจิกเดียวกันจะทํางานเช่นเดียวกับ SSE4.1 (4 พิกเซล) หรือ AVX2 + FMA (8 พิกเซล) ที่เลือกในเวลาทํางาน การตรวจจับคุณลักษณะเกิดขึ้นครั้งเดียวต่อ diff และเส้นทาง SIMD ที่เร็วที่สุดที่มีอยู่จะใช้สําหรับการดําเนินงานทั้งหมด ไม่มีการส่งออกระยะเวลาการทํางานต่อพิกเซล พอร์ต Rust เริ่มต้นสอดคล้องกับประสิทธิภาพระดับ Odiff อัลกอริทึมเดียวกันภาษาที่แตกต่างกันและทันทีการทํางานของ overhead ได้หายไป การเพิ่มประสิทธิภาพผ่าน: ทําให้การกัดกร่อนเร็วขึ้นอย่างมีนัยสําคัญ การจับคู่ odiff เป็นขั้นตอนพื้นฐาน หลายรอบของการเพิ่มประสิทธิภาพกระตุ้น BlazeDiff ยิ่งไปกว่านั้น 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 ผลต่อ Odiff (รวมทั้งภาพเต็มรูปแบบ I / O: decode, 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 × 3200) 1190.92 มม 293.86 มม 75.3% 4K / 2 1530.21 มม 363.50 มม 76.2% 4K / 3 1835.47 มม 389.67 มม 78.8% หน้าแรก / 1 1035.20 มม 472.99 มม 54.3% หน้าหลัก / 2 598.79 มม 263.90 มม 55.9% 3-4 เท่าที่เร็วขึ้นในภาพ 4K การรวมกันของบล็อก-based early exit, SIMD vectorization, parallel I/O, and aggressive compiler optimization เพิ่มขึ้น ปัญหาการบูรณาการ: ได้รับ Rust ใน JavaScript มีไบนารี Rust ที่รวดเร็วเป็นสิ่งที่ดี แต่ผู้ใช้เป้าหมายคือนักพัฒนา JavaScript ที่เขียนการทดสอบภาพด้วย Playwright, Cypress หรือ Vitest พวกเขาต้องการ ไม่ . npm install cargo install วิธีการแรกเป็นสิ่งที่ชัดเจน: Node.js → spawn binary → run diff → return result บรรจุไบนารี Rust ในแพคเกจ Node.js พืชมันเป็นกระบวนการเด็กและวิเคราะห์การส่งออก JSON: try { await execFileAsync(binaryPath, args); return { match: true }; } catch (err) { // Parse exit codes: 0=identical, 1=pixel-diff, 2=error } สิ่งนี้ทํางาน มันเรียบง่ายพกพาและไบนารีจัดการการยกหนักทั้งหมด แต่ในท่อ CI diffing 500 ภาพหน้าจอคุณกําลังสร้างกระบวนการ 500 การสร้างกระบวนการไม่ได้เป็นอิสระ ฟอร์ก, exec, การ์ตูนหน่วยความจํา, โหลดห้องสมุดที่ใช้ร่วมกัน โหลด overhead per spawn นั้นเล็ก แต่ก็เพิ่มขึ้น ใบเสนอราคาแสดงให้เห็นว่ามันกิน 30-40% ของเวลาทั้งหมดในภาพขนาดเล็กที่ diff จริงใช้เวลา <5ms ทําไมไม่เป็นเซิร์ฟเวอร์ Diff แบบคงที่ odiff แก้ไขปัญหานี้โดยการเรียกใช้กระบวนการเซิร์ฟเวอร์ที่คงที่ คุณเริ่มมันครั้งเดียวส่งคําขอ diff ผ่านโซ็คเก็ตและจัดการกับพวกเขาโดยไม่ต้องใช้ spawn overhead ฉันพิจารณาวิธีการนี้และปฏิเสธมัน ความต้านทานไม่พอดีกับกรณีการใช้: ความซับซ้อน เซิร์ฟเวอร์หมายถึงการจัดการวงจรชีวิต: เริ่มต้นก่อนการทดสอบหยุดหลังจากจัดการความผิดพลาดและจัดการพอร์ต Statefulness กระบวนการที่ดําเนินการเป็นเวลานานสะสมรัฐ การรั่วไหลของหน่วยความจํากลายเป็นปัญหา (ฉันเกิดขึ้นในเรื่องนี้ในภายหลังด้วย mimalloc) การบูรณาการ CI สภาพแวดล้อม CI เป็นขั้นตอน การเพิ่มเดโมนเซิร์ฟเวอร์ทําให้ภาพ Docker, กระบวนการทํางานของ GitHub Actions และการแก้ไขปัญหาซับซ้อน การออกแบบ API ฉันต้องการว่าแต่ละการดําเนินการ diff จะเป็นแบบอะตอมและมีส่วนร่วมในตัวเอง การเปรียบเทียบ (a, b) ควรทํางานได้โดยไม่จําเป็นต้องผู้ใช้จัดการตัวอย่างเซิร์ฟเวอร์ วัตถุประสงค์ในการออกแบบที่ชัดเจน: ประสิทธิภาพในประเทศที่มีความเรียบง่ายของการเรียกฟังก์ชั่น การเรียนรู้จาก Rust-Based JavaScript Tooling คําตอบมาจากการศึกษาว่าเครื่องมือ JavaScript อื่น ๆ ที่ใช้ Rust จะจัดการกับปัญหานี้อย่างไร (the linter/formatter) ใช้สถาปัตยกรรมที่สะอาดโดยเฉพาะอย่างยิ่ง: ไบโอเมล์ JavaScript API → N-API binding (.node file) → Rust core library ความเข้าใจที่สําคัญคือ — ABI ที่มั่นคงของ Node.js สําหรับ addons ธรรมชาติ แทนที่จะทําให้เกิดกระบวนการของเด็กรหัส Rust รวบรวมเป็น คู่สมุดที่ใช้ร่วมกันที่โหลดโดยตรงไปยังกระบวนการ Node.js การเรียกฟังก์ชั่นจาก JavaScript ไปยัง Rust จะกลายเป็นการเรียกป้ายฟังก์ชั่นโดยตรง ไม่มี serialization ไม่มี IPC ไม่มีกระบวนการ overhead N-API .node กลยุทธ์การบรรจุเป็นสิ่งสําคัญเท่าเทียมกัน แพลตฟอร์มที่เฉพาะเจาะจงไบนารีจะเผยแพร่เป็นแพคเกจ npm แบบแยกต่างหากด้วย และ พื้นที่ : os cpu { "name": "@blazediff/bin-darwin-arm64", "os": ["darwin"], "cpu": ["arm64"], "files": ["blazediff", "blazediff.node"] } แพคเกจหลักรายการเหล่านี้เป็น : 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 เท่านั้นติดตั้งแพคเกจที่สอดคล้องกับแพลตฟอร์มปัจจุบัน ไม่มีสคริปต์หลังการติดตั้ง ไม่มีการรวบรวม เท่านั้นเป็นไบนารีที่สร้างไว้ล่วงหน้า โครงสร้างขั้นสุดท้าย: Rust + N-API สถาปัตยกรรมขั้นสุดท้ายของ BlazeDiff ใช้วิธีการระดับ การผูกพัน N-API เป็นเส้นทางที่รวดเร็ว การสร้างไบนารีเป็นความล้มเหลว 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 ถูกกําหนดด้วย 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), }) } ในด้าน JavaScript ตัวเชื่อมโยงจะโหลดได้อย่างเบื่อและแคชผลลัพธ์: 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; } การกําหนดค่า Cargo รวบรวมเครือข่ายเดียวกันกับไบนารีอิสระและ cdylib (ห้องสมุดที่ใช้ร่วมกันสําหรับ N-API) [lib] name = "blazediff" crate-type = ["lib", "cdylib"] [features] default = [] napi = ["dep:napi", "dep:napi-derive"] หนึ่งรหัสฐานสองเป้าหมายการกระจาย: โมดูล CLI binary และ Node.js native การเพิ่มประสิทธิภาพ SIMD เดียวกันอัลกอริทึมที่ใช้บล็อกเดียวกันทุกอย่างเดียวกันเพียงจุดเข้าที่แตกต่างกัน บทเรียนที่เรียนรู้ 1. อัลกอริทึมก่อนภาษา การออกแบบที่ขึ้นอยู่กับบล็อกทําให้เกิดการเพิ่มความเร็ว 72-88% ใน JavaScript เท่านั้นก่อนที่จะเขียน Rust ใด ๆ การเลือกอัลกอริทึมที่เหมาะสมมีความสําคัญมากกว่าการเลือกภาษาที่เหมาะสม หากฉันไปตรงไปยัง Rust ด้วยวิธีการพิกเซลต่อพิกเซลฉันจะมีสแกนเนอร์พิกเซลที่รวดเร็วแทนที่จะแตกต่างจากภาพที่รวดเร็ว 2. JavaScript มีเพดานที่แข็งแกร่งสําหรับการทํางานตัวเลข เมื่ออัลกอริทึมได้รับการเพิ่มประสิทธิภาพการทํางานของ JavaScript overhead - GC pauses, JIT warmup, การขาด SIMD, property lookup chains - ได้กลายเป็นค่าใช้จ่ายที่โดดเด่น สําหรับวงกุญแจตัวเลขที่เข้มงวดกว่ากระป๋องขนาดใหญ่ไม่มีปริมาณการเพิ่มประสิทธิภาพไมโครสามารถเอาชนะ V8 overhead นี่ไม่ใช่การวิจารณ์ของ JavaScript เป็นการยอมรับว่าเครื่องมือที่แตกต่างกันให้บริการวัตถุประสงค์ที่แตกต่างกัน 3. อาคารกระบวนการมีความสําคัญเท่ากับการออกแบบอัลกอริทึม การกระโดดจาก ไปยัง N-API เป็นการปรับปรุงที่ใหญ่กว่าการเปลี่ยนแปลงอัลกอริทึมบางอย่าง การตัดสินใจทางสถาปัตยกรรม - วิธีการเรียกใช้รหัสวิธีการถ่ายโอนข้อมูลวิธีการจัดการวงจรชีวิตกระบวนการ - รวมกับแต่ละการโทร เมื่อคุณ diffing 500 ภาพความแตกต่างระหว่างการเรียกฟังก์ชั่นและกระบวนการ spawn คือความแตกต่างระหว่างวินาทีและนาที spawn(binary) 4. N-API เป็นสะพานที่ต่ํากว่า N-API ให้ ABI ที่มั่นคงทั่ว Node.js รุ่นแพลตฟอร์มเฉพาะแพคเกจที่สะอาดผ่าน เป็นวิธีการเดียวกันที่ใช้โดย Biome, SWC และเครื่องมือ JavaScript ประสิทธิภาพสูงอื่น ๆ หากคุณกําลังสร้างห้องสมุด JavaScript ที่สําคัญต่อประสิทธิภาพและ JavaScript ตัวเองเป็นขีดข่วน N-API + Rust เป็นเส้นทางที่ได้รับการพิสูจน์แล้ว optionalDependencies 5. benchmark ทุกอย่างไม่ไว้วางใจอะไร การเพิ่มประสิทธิภาพแต่ละครั้งได้รับการยืนยันโดยใช้ benchmarks ที่ทํางานบนฮาร์ดแวร์ที่สอดคล้องกัน เส้นทาง WASM ได้รับการสํารวจและทิ้งไว้ (ฉันพยายามทั้ง Rust WASM และ AssemblyScript - ทั้งสอง ๆ นั้นช้ากว่าเดิมสําหรับโหลดงานนี้) สูตรขนาดบล็อกได้รับการปรับแต่งทางประสบการณ์ในขนาดภาพตั้งแต่ 100 × 100 ถึง 5600 × 3200 ความเข้าใจเกี่ยวกับประสิทธิภาพมักจะผิด การวัด JavaScript ยังคงเป็นหนึ่งในระบบนิเวศที่ดีที่สุดสําหรับเครื่องมือนักพัฒนา: เรื่องราวผู้จัดการแพคเกจการทดสอบการบูรณาการกรอบและความกว้างของชุมชน แต่บางครั้งเส้นทางที่เร็วที่สุดไปข้างหน้าคือปล่อยให้รหัสพื้นฐานทําการยกหนักในขณะที่ JavaScript ยังคงเป็นอินเตอร์เฟซที่นักพัฒนารัก BlazeDiff เรือเป็นเดี่ยว . ภายใต้ฝาครอบมันเป็น 2,000 สายของพิกเซลการประมวลผล Rust ที่ได้รับการเพิ่มประสิทธิภาพจาก SIMD ผ่านอัลกอริทึมบล็อกสองผ่าน จากมุมมองของผู้พัฒนามันเป็น . npm install compare(a, b) นี่คือเป้าหมาย: ประสิทธิภาพที่มองไม่เห็น ผู้ใช้ไม่ควรรู้หรือกังวลว่า Rust มีอยู่