Profiler Olmadan Performans Tahmini Neden Yanıltıcı

Yazılımcı olarak bir kodu hızlandırmaya karar verdiğinde ilk yapılan genellikle şu olur: "Bu kısım yavaş olmalı, oraya bakalım." Sonra döngü açılır, string concatenation bulunur, veya bir liste kopyalaması göze çarpar. Sonra da değişiklik yapılır, "Kesinlikle hızlandı" denir. Ama profiler açıldığında çoğu zaman hiç bir şey değişmemiştir.

Bu, yazılım performansının en yaygın yanlış anlaşılmasıdır. İnsan beyni, kodda neyin yavaş olduğunu tahmin etmede inanılmaz derecede kötüdür. Bir fonksiyonun yüzde 80'ini harcayan kodu görmezden gelip, yüzde 2'lik bir döngüyü optimize etmek çok kolaydır.

Gerçek sorun şudur: CPU cache, branch prediction, compiler optimizations ve runtime behavior hakkında sezgi geliştirmek çok zordur. Bir diziye erişim, bir fonksiyon çağrısı, bir bellek ayırma işlemi, bunların her birinin maliyeti bağlama göre değişir. Aynı kod, farklı veri setleriyle çalıştırıldığında tamamen farklı performans gösterebilir.

Microsoft'un eski bir çalışmasında geliştiricilerin tahmin ettikleri performans병목(bottleneck) yerleri ile profiler'in bulduğu yerler karşılaştırılmıştı. Başarı oranı yüzde 30'un altındaydı. Yani altı tahmininden beşi yanlıştı.

Bu neden önemli? Çünkü micro-optimization avı zaman kaybettirir. Bir geliştirici, yanlış yere bakarak saatler harcayabilir. O saatler, gerçek병목 yerlerini bulmaya veya algoritma değiştirmeye harcanabilir. Algoritma değişikliği, genellikle micro-optimization'dan yüz kat daha etkilidir.

Doğru yaklaşım basittir: Ölçümle başla. Profiler aç, kodu çalıştır, verileri oku. Sonra optimize et. Go'da pprof, Python'da cProfile, C#'ta dotTrace gibi araçlar var. Bunlar ücretsiz veya ucuzdur.

Profiler olmadan "bu hızlandırılmalı" demek, tıbbi teşhis yapmadan ameliyat planlamak gibidir. Sonuç, çoğu zaman hastaya zarar verir. Performans optimizasyonunda da aynıdır: ölçümü atlayan optimizasyon, genellikle kodu karmaşıklaştırır ve hiç bir şey kazandırmaz.