Node.js 26'nın Map.getOrInsertComputed'si, get-ve-set kalıbına kıyasla benchmarklarda %40'a varan yavaşlık gösteriyor

Node.js 26, uzun süredir istenen iki Map metodu getOrInsert() ve getOrInsertComputed()'yı getiren V8 14.6 ile geliyor; her ikisi de WeakMap üzerinde kullanılabiliyor. Bu metotlar, alışık olduğumuz arama-hesaplama-depolama-döndürme bloğunu tek bir çağrıya indiriyor. Ancak alexgeorgiv17 tarafından dev.to'da yayımlanan benchmarklar, computed varyantının yerini aldığı kalıptan daha yavaş olduğunu gösteriyor: tamamen miss geçen bir iş yükünde yaklaşık %18, sıcak cache ile ise yaklaşık %40 daha yavaş — ki bu, gerçek cache'ler için tipik senaryodur.

Testler, 28 Ekim 2026 tarihli "Lithium" sürümü olan ve V8 14.6.202.34-node.40 içeren Node 26.13.0 üzerinde çalıştırıldı.

Benchmark nasıl yapıldı

process.hrtime.bigint() ile iki iş yükü zamanlandı: her çağrının miss olduğu beş milyon benzersiz anahtar eklemesi ve her çağrının isabet olduğu 1.000 anahtara yayılmış beş milyon arama. Rapor edilen rakamlar, beş ile dokuz tekrarın en hızlısı ve medyanıdır.

• Tamamı miss: klasik get-sonra-set dizisi medyan 1.678 ms sürerken, getOrInsertComputed için bu süre 1.978 ms oldu; yaklaşık %18 daha yavaş.
• Tamamı isabet: 29,7 ms'a karşı 41,6 ms; yaklaşık %40 daha yavaş.

Sıcak bir cache'de bu kadar büyük bir fark inandırıcı gelmediği için yazar, CPU frekansı ve cache ısınması kaynaklı kaymayı dengelemek amacıyla uygulamaların dokuz çalışmada sırasını dönüşümlü değiştirdiği egzersizi tekrarladı ve üçüncü bir yarışmacı daha ekledi: native metodu taklit eden, map'i, anahtarı ve callback'i parametre alan düz bir JavaScript fonksiyonu. Yerleşik metot her iki sıralamada da üçlüyü sonuncu bitirdi; elle yazılmış wrapper, motorun kendi metodundan hiçbir zaman daha yavaş kalmadı ve kimi zaman onu geçti.

Muhtemel açıklama — motorun dışından doğrulanamayacağı için yazarın test edilmemiş bir hipotez olarak belirttiği üzere — V8'nin optimize edici derleyicisinin yıllardır get ve set'i inline edilebilir monomorfik çağrılar olarak özelleştirmiş olması, yeni metodun ise bu sürümde henüz aynı muameleyi görmemiş olmasıdır.

Kazanç: eşzamanlı asenkron işin yerleşik tekilleştirilmesi

Metodun gerçekten işe yaradığı yer asenkron doğruluk. Ekleme senkron gerçekleştiği için, çözümlenmiş değerler yerine promise'leri önbelleğe almak, aynı anahtar için eşzamanlı isteklerin tek bir hesaplamayı paylaşması anlamına geliyor. dev.to'daki örnekte, bir anahtar için yapılan üç eşzamanlı istek ile farklı bir anahtar için yapılan bir istek, toplamda yalnızca iki kez fetching fonksiyonunun çalıştırılmasına yol açtı. Bu, yavaş bir backend'e karşı istek yığılmalarını önlemek için sunucu kodunda elle yazılan in-flight promise takibini tek satırda yeniden üretiyor.

Önbelleğe alınan reddetmeler ve göz ardı edilen yan etkiler

Aynı davranış keskin uçlar da içeriyor. Reddedilen bir promise, gerçekleşen bir promise gibi depolanıyor ve hiçbir şey onu geçersiz kılmıyor: yazarın gösteriminde, bir kez başarısız olup sonra başarılı olacak şekilde tasarlanmış bir fonksiyon ikinci denemesini hiç alamadı, çünkü ilk red kalıcı olarak anahtar altına depolandı ve sonraki her çağıran eski hatayı aldı. Metodu ağ çağrılarını tekilleştirmek için kullanan herkes, başarısız anahtarı silen kendi catch handler'ını eklemek zorunda.

Ayrıca metot, callback açısından atomik değil. Motor, callback'i çağırmadan önce anahtarın eksik olduğunu kaydediyor, sonra callback bu anahtarla arasında ne yaptığına bakmaksızın callback'in dönüş değerini yazıyor — callback içinde yapılan bir set sessizce eziliyor, hatta anahtarın silinmesi bile geri alınıyor ve anahtar döndürülen değeri tutarak yeniden beliriyor.

Neden önemli

Bu metotlar boilerplate'i replace etmek için eklendi, dolayısıyla memoisation ve cache kodlarında hızla yayılmaları muhtemel. dev.to rakamları, bugün getOrInsertComputed'yu benimseyen hot path'lerin, en azından V8 yeni metoda get ve set ile aynı optimizasyon ilgisini gösterene kadar ölçülebilir bir bedel ödediğini düşündürüyor. Eşzamanlı iş tekilleştirmesi, I/O-bağımlı kod için gerçek bir fayda; ancak hataların süresiz önbelleğe alınması bir üretim riski: tek bir geçici hata, bir şey o girdiyi açıkça kaldırana dek cache kaydını zehirleyebilir. Node 26'daki geliştiriciler ikisinin de en iyisini, sıcak senkron yollarda düz get ve set'i koruyup yeni metodu, baştan itibaren hata yolu geçersiz kılmayı da ekleyerek, eşzamanlı asenkron iş için ayırarak alabilir.