Her ekibin bir "en hızlı yol" listesi vardır: döngüdeki string birleştirmeyi değiştirmek, gereksiz bir efekt kaldırmak, sorguyu elle yazmak. Bu liste, ölçmeden uygulandığında kodu okunmaz yapan ama hız kazandırmayan bir süse dönüşür. Profil almadan yapılan optimizasyon, avcılık değil körleme avcılığıdır: nereye nişan aldığınızı bilmeden tetiği çekmek. Avcının hikâyesi de genelde aynıdır: iki saat süren mikro düzeyde iyileştirme, sonrasında ölçümde görünmeyen bir darboğaz ve okunamayan bir fonksiyon.

Neden ölçmeden düzeltmek yanlış?

Bir fonksiyonun yavaş olduğu hissi, çoğu zaman maliyeti büyüyen koddan değil, en çok gözden kaçan koddan gelir. Gerçek dağılımı genelde şaşırtıcıdır: çağrıların çoğunluğunun hızlı, azınlığının yavaş olduğu bir fonksiyonda ortalama optimizasyon, çoğu kullanıcıyı düzeltmez. Sadece kodu karmaşıklaştırır; okuyan geliştirici, bu karmaşanın bir gün derli toplu ölçülmüş bir karara dayandığını sanır. Ölçüm, hız iyileştirmesini hissiyatın elinden alıp belgeye bağlayan tek araçtır.

// His: "reduce yavaş, döngüye çevirelim" — ölçüsüz karar
// Ölçüm: darboğaz veritabanı sorgusundaymış
const rapor = await perfy(async () => {
  const satirlar = await db.select().from(siparisler).where(eq(siparisler.durum, "acik"));
  return satirlar.length;
});
console.info("sorgu süresi", rapor.ms);

Ölçmeden önce bir soru sorulmalıdır: yavaşlık nerede hissediliyor, hangi kullanıcıda, hangi veri büyüklüğünde? Bu sorunun cevabı olmayan optimizasyon, hedefsiz atıştırmasıdır. Yüz kullanıcının çoğunluğunun beklemediği bir yolu hızlandırmak, bütçenin en pahalı harcamasıdır. Ölçümün bir diğer yan faydası da beklentiyi sabitlemektir: "yavaş" diyen kullanıcı, aslında üç saniyelik bir sayfanın mı, sekiz saniyelik bir sorgunun mı şikâyetçisi? Ölçüm, tartışmayı hissiyatın elinden alır.

Profil nasıl alınır?

Tarayıcı tarafında Performance sekmesi, Node tarafında CPU profili veya clinic, veritabanında sorgu planı. Ortak ilke: önce darboğazı gör, sonra onu büyütmeyi dene. Aynı ölçümü iki kez alamıyorsan ortam karışıktır; ölçüm yapamıyorsan iyileştirme yapamazsın. Ölçüm ortamını sabitlemek de işin yarısıdır: aynı veri, aynı istek dizisi, aynı önbellek durumu. Ortam sabit değilse fark, kodunuzun değil koşulların eseridir.

-- Beklenen: index scan, gerçekte: full scan
EXPLAIN QUERY PLAN
SELECT id, baslik FROM posts WHERE kategori = 'Yazılım' ORDER BY tarih DESC;

Ölç, düzelt, yeniden ölç

Sağlıklı döngü üç adımdır: profili al, tek bir değişiklik yap, aynı ölçümü tekrarla. Değişiklik kazandırmıyorsa geri alın; kazandıysa önceki profille karşılaştırılabilir bir kayıt bırakın. Bu kayıt, altı ay sonra "bu fonksiyon neden böyleydi" sorusunun tek cevabıdır ve ekibin en değerli mühendislik hafızasıdır. Kayıtsız iyileştirme, altıncı geliştiricinin elinde geri alınır; çünkü kazancı kimse hatırlamaz, karmaşası ise ortadadır. Döngünün başında da bir söz verilmelidir: kazanç yüzde onun altında kalırsa değişiklik geri alınır. Küçük kazanç için okunabilirlik kaybı çoğu zaman iyi bir pazarlık değildir; eşiği baştan belirlemek, tartışmayı hissiyattan çıkarır.

Son söz: hız, his değil ölçümdür. Profil almak saniyeler sürer; ölçülmeyen optimizasyon ise saatlerce sürer ve faturayı önce okunabilirlik, sonra kullanıcı öder. Bir sonraki "burayı hızlandırayım" refleksini yakaladığınızda yapılacak tek şey var: önce profili açın, sonra konuşun.