Photoshop’ta MSVC ve SPGO ile %20 Hız Artışı: Nasıl Oldu?
Bakın, ben senelerdir Azure tarafında çalışan biri olarak compiler iyileştirmeu haberlerine genelde “iyi bari” deyip geçerdim. Ama bu Adobe-Microsoft işbirliği biraz daha dikkatimi çekti. Sebebi de şu: Photoshop gibi 30 yıllık, devasa bir C++ uygulamasında fırça gecikmesini %20 azaltmak — kulağa basit geliyor ama altında ciddi bir mühendislik var.
Üstelik konu sadece “derleyici güncellendi, hızlandı” değil (yanlış duymadınız). Burada işin özünde, Adobe’un yıllardır boğuştuğu bir problemin (instrumentation-based PGO’nun pratikte çalışmaması) yeni bir yaklaşımla çözülmüş olması yatıyor. Sample-based PGO yanı SPGO ile. Şimdi bunu açayım, hem teknik tarafını hem de “peki bizim Türkiye’deki yazılım ekiplerini nasıl ilgilendirir” kısmını konuşalım.
Önce Şu Rakamlara Bir Bakalım
Adobe’un yayınladığı benchmark’a göre Photoshop’un Windows tarafında x64’te %20, ARM64’te işe %13 performans artışı sağlanmış. Bu rakamlar fırça hareketi, dosya açma, stroke responsiveness gibi kullanıcının doğrudan hissettiği senaryolarda ölçülmüş. Yanı sentetik bir CPU benchmark’ı değil, gerçek workflow.
%20 demek ne demek? Bir tasarımcının günde 8 saat çalıştığını düşünün. Fırçayı her hareket ettirdiğinde mikro saniyelerle bile olsa bir gecikme varsa, bu gün sonunda yaratıcı akışı bozuyor; bazen insanın canını sıkıyor, bazen de işi tamamen dağıtıyor. Sahada gördüğüm kadarıyla — itiraz edebilirsiniz tabi — dijital sanatçılar bu tip gecikmeleri artık “rahatsız edici” diye anlatmıyor bile — direkt başka programa kayıyorlar. O yüzden Adobe için bu baya planlı bir kazanım.
İşte tam da bu noktada devreye giriyor.
%20’lık hız artışı kağıt üstünde basit bir rakam. Ama bunu elde etmek için kaynak kodda tek satır değişiklik yapılmadığını düşünürseniz, derleyici tarafının ne kadar derin bir iş yaptığını anlarsınız.
Klasik PGO Neden Photoshop’a Yaramadı?
Profile-Guided Optimization, yanı PGO, aslında yıllardır var. Mantığı basit: Önce uygulamayı özel bir “instrumented” modda derliyorsunuz. Bu binary çalışırken hangi fonksiyonların ne sıklıkta çağrıldığını, hangi branch’lerin daha çok kullanıldığını topluyor. Sonra bu veriyi derleyiciye verip “şu hot path’lere odaklan” diyorsunuz.
Teoride harika dürüyor. Pratikte işe… şey, şöyle anlatayım: Photoshop gibi devasa bir uygulamayı instrumented modda derlediğinizde build süresi uzuyor, çıkan binary baya yavaşlıyor (zira her fonksiyon çağrısına telemetri kodu giriyor),. Sonuçta “gerçek kullanım profilini” temsil eden veri toplayamıyorsunuz. Adobe ekibi bu modeli daha önce denemiş; training run’ları operasyonel timeout’lara takılmış. Yanı topladıkları veri zaten gerçek dünyayı tam yansıtmıyormuş.
Şimdi gelelim işin can alıcı noktasına.
Şunu fark ettim: Bu durumu kurumsal C++ projelerinde sıkça görüyorum. Klasik PGO küçük-orta ölçekli projelerde idare ediyor. Milyonlarca satır kodlu, bağımlılığı böl ürünlerde “instrument et, çalıştır, profile topla, yeniden derle” döngüsü pek uzun vadeli olmuyor (şaşırtıcı ama gerçek). CI/CD’ye sokmaya kalkın; build farm’ın nefesi daralıyor.
İşin Aslı Şu Ki…
Klasik PGO’nun en büyük problemi sürdürülebilirlik. Bir kere yapıp bırakırsanız kod değiştikçe profil verisi bayatlıyor; sürekli yapacaksanız da build pipeline’ınızı buna göre kurmanız gerekiyor — ki bu da ek ekip demek, ek maliyet demek, biraz da sabır demek.
SPGO Devreye Giriyor: Sample-Based Yaklaşım
SPGO’nun farkı şurada: Instrumented build’e ihtiyaç yok. Normal release binary’sını alıp gerçek workload’ları çalıştırıyorsunuz; işletim sistemi seviyesinde sampling yapan profiler (Windows’ta ETW tabanlı) hangi instruction’ların ne sıklıkta çalıştırıldığını topluyor. Sonra bu veri MSVC’ye besleniyor ve derleyici “aha, bu fonksiyon hot; buna göre inline et, register allocation’da buraya öncelik ver” diye karar veriyor.
Peki neden? GitHub Code Quality artık ücretli: Kurumlar neyi hesap etmeli? yazımızda bu konuya da değinmiştik. PowerToys 0.100: Shortcut Guide ve Command Palette Yenilendi yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı yazımıza da göz atmanızı tavsiye ederim.
Vallahi, Avantajları şöyle sıralayayım: Bu konuyla ilgili Claude Fable 5 Microsoft Foundry’de: Otonom Ajan Devri Başlıyor yazımıza da göz atmanızı tavsiye ederim.
- Production binary’sinden profil toplanıyor — yanı temsil ediciliği yüksek
- Build pipeline’da özel bir konfigürasyona gerek yok
- Sampling overhead’i çok düşük kalıyor; gerçek kullanıcı senaryoları rahatça çalışabiliyor
- Kaynak kodda değişiklik gerekmiyor; sadece compiler flag’leri yetiyor
Bir de tabi MSVC’nın peak-performance ayarlarının üstüne geliyor bu iş. Yanı /GL ile whole program optimization ve LTCG (link-time code generation) zaten açık olmalı. SPGO bunların üstüne binen ekstra bir katman gibi davranıyor. Adobe ekibi önce temel ayarların düzgün olduğundan emin olmuş, sonra SPGO’ya geçmiş; sıralama burada önemliymiş.
Peki MSVC Tarafında Nasıl Etkinleştiriliyor?
Araya gireyim: Genel akış kabaca şöyle ilerliyor. Tabiî Photoshop ölçeğinde her adımın içinde ayrı mühendislik var (buna dikkat edin). Mantığı görmek için aşağıdaki iskelet yeterli oluyor: (en azından benim deneyimim böyle)
# 1. Release build'i peak-performance flag'leriyle derle
cl /O2 /GL /Gw /Gy main.cpp
link /LTCG main.obj
# 2. Production binary'sini representative workload ile çalıştır
# ETW tabanlı sampling ile profil topla
xperf -on PROC_THREAD+LOADER+PROFILE
#... workload çalıştırılır...
xperf -d profile.etl
# 3. Profil verisini SPGO formatına dönüştür ve yeniden derle
cl /O2 /GL /Gw /Gy /GENPROFILE:PATH=profile.pgd main.cpp
link /LTCG /USEPROFILE:PGD=profile.pgd main.obj
Bu sadece kavramsal bir taslak — gerçek üretimde toolchain biraz daha karmaşık oluyor ama mantık aynı kalıyor. Ve dikkat edin: kod tek satır değişmedi; yalnızca derleyiciye “şu binary böyle çalışıyor, buna göre optimize et” dedik.
x64 vs ARM64 Farkı Niye Önemli?
Yanı, x64’te %20, ARM64’te %13 çıkmış olması ilk bakışta “neden ARM daha az kazandı?” sorusunu getiriyor olabilir. Aslında işin doğası biraz böyle ilerliyor; ARM64 mimarisi daha fazla register’a sahip ve instruction set’i daha düzenli olduğu için baseline’da zaten görece iyi kod üretiyor. x64 tarafında işe legacy mimariden gelen kısıtlar (az register meselesi, complex instruction encoding falan) iyileştirme için daha fazla manevra alanı bırakabiliyor. Bu konuyla ilgili Copilot Autofix Azure DevOps’ta: Alert Yığını Bitiyor mu? yazımıza da göz atmanızı tavsiye ederim.
ARM64 tarafında %13 bile az değil hani. Hele bir de — ki bu tartışılır — Surface Pro X ya da Copilot+ PC’ler gibi ARM tabanlı Windows cihazlarda Photoshop’un akıcı çalışması Microsoft açısından stratejik kalıyor. Bu cihazlar pil ömrü için optimize ediliyor ama performans yine kritik; SPGO burada hem hız hem de enerji verimliliği kazandırabiliyor çünkü daha az instruction çalıştırılıyor ve doğal olarak daha az enerji gidiyor.
Türkiye’deki C++ Ekipleri İçin Ne Anlama Geliyor?
Şimdi gelelim asıl soruya bence burada dönüp dolaşıp ona geliyoruz zaten Türkiye’de native C++ ile büyük masaüstü uygulaması geliştiren ekip sayısı çok fazla değil ama olanlar — finans tarafında risk hesaplama sistemleri, oyun stüdyoları, CAD/CAM yazılımları, medikal görüntüleme işleri — bu tarz iyileştirmelardan ciddi fayda görebilirler.
Performans-kritik uygulamalarda hâlâ alternatif yok gibi düşünün; web güzel tamam ama bazı işler var ki orada CPU’nun nefesi doğrudan hissediliyor.
Kurumsal C++ ekiplerinde gördüğüm en yaygın hata şu: MSVC’nın gelişmiş iyileştirme flag’lerini açmayı unutuyorlar ya da “build süremiz uzar” diye kapatıyorlar.
/GL. /LTCG kapalı bir release build’ınız varsa masada ciddi performans bırakıyorsunuz demektir.
SPGO’ya gelmeden önce şu temel kontrolü yapın:
| Flag | Ne Yapar? | Maliyet |
|---|---|---|
/O2 |
Hız için tam iyileştirme | Build süresi az artar |
/GL |
Whole program optimization | Build süresi belirgin artar |
/LTCG |
Link-time code generation | LInk süresi çok artar |
/Gw |
Optimize global data | Ihmal edilebilir |
/Gy |
Function-level linking | Ihmal edilebilir |
| SPGO | P rofile-driven optimization | P rofil toplama altyapısı gerekir |
Küçük ekipseniz — diyelim 5-10 kişilik bir oyun stüdyosu — SPGO’ya hemen atlamayın.
Önce /O2 /GL /LTCG kombinasyonunu doğru yapılandırın.
Bu bile birçok projede %5-10 kazandırabiliyor.
Enterprise seviyede ve büyük binary’lere sahip projelerdeyse SPGO için yatırım yapmaya değer oluyor.
representative workload seçimi sonucun kalitesini doğrudan belirliyor.
Yanı sadece “uygulamayı beş dakika açık tut” yetmiyor;
gerçek kullanıcı senaryolarını otomatize etmeniz gerekiyor.
Yoksa ölçüm var gibi görünür ama elde kalan şey biraz zayıf olur.
SPGO’nun Görünmeyen Maliyeti
Açık konuşayım:
SPGO bedava değil.
Profil toplama altyapısı kurmak gerekiyor.
Yanı sadece compiler flag açıp bitmiyor.
Şunları planlamanız lazım:
- [ ] Representative workload üretmek için otomasyon
Kullanıcı senaryolarını UI seviyesinde simüle eden test suite’leri gerekir;
- [ ] ETW veya benzeri sampling profiler entegrasyonu
CI/CD pipeline’a sokulması gerekir;
- [ ] Profil verisinin versiyonlanması
Kod değiştikçe profilin de güncellenmesi gerekir;
- [ ] İki aşamalı build pipeline
Önce baseline build,
sonra profil ile rebuild gerekir;
Bütün bunlar küçük ekip için fazla olabilir.
Ama Photoshop ölçeğinde bir ürününüz varsa bu yatırımın geri dönüşü hızlı olur;
%1 performans artışı bile milyonlarca kullanıcıda toplamda devasa enerji ve zaman tasarrufu demek olabilir.
Bu arada konu MSVC olunca,
eğer build toolchain’inizle ilgili güncellemeleri de takip ediyorsanız MSVC Build Tools Haziran 2026 Önizleme: Sessiz Ama Derin İyileştirmeler
yazımdaki değişikliklere de göz atmanızı öneririm.
Orada da benzer
“sessiz ama etkili”
iyileştirmeler vardı.
GPU Varken CPU Optimizasyonu Hâlâ Önemli mi?
Birinin
”
günümüzde her şey GPU’ya kayıyor, CPU optimize etmeu eski moda”
diyeceğini duyar gibiyim.
Yanılıyorsun.
Photoshop örneği tam da bunu gösteriyor.
Evet, image processing filtreleri büyük oranda GPU’ya taşındı.
Ama kullanıcının latency hissettiği yerler
— fırça anlık tepkisi, dosya açma, UI responsiveness
— hâlâ CPU’ya bağlı.
Çünkü bu işlemlerin GPU’ya gitme overhead’i, işlemin kendisinden büyük olabiliyor.
Bence bu önemli bir ders.
AI ve GPU coşkusu içinde
”
CPU artık önemli değil”
gibi bir algı oluşuyor.
Halbuki uygulamanızın kullanıcıya hissettirdiği gecikmenin çoğu hâlâ CPU tarafında kalıyor. Hot path’leriniz hangi tarafta işe oraya yatırım yapacaksınız. Profil olmadan bunu bilemezsiniz. SPGO bu yüzden değerli — varsayım yapmıyor, ölçüyor.
Eleştirim : Daha Kolay Olabilirdi
Adobe-Microsoft hikâyesi güzel ama dürüst olalım :
SPGO’nun setup’ı hâlâ küçük ekipler için yorucu.
Microsoft’un bu konuda daha hazır şablonlar,
Visual Studio entegrasyonu sunmasını isterdim.
Linux tarafında AutoFDO benzer yaklaşımıyla zaten yıllardır var ve toolchain’i biraz daha olgun dürüyor.
MSVC tarafında SPGO yeni kapı açıyor ama hâlâ “advanced users only” hissi veriyor.
Umarım önümüzdeki sürümlerde bu olgunlaşır. Çünkü potansiyeli büyük.
Eğer Visual Studio’da tek checkbox ile açılabilir hâle gelirse çok daha fazla ekip faydalanır.
Şu anki hâliyle biraz “elit kulüp” gibi dürüyor.
Geliştirici verimliliği açısından da bakacak olursak,
Visual Studio’dan Çıkmadan Pull Request İncelemek : Artık Daha Rahat
yazımda da değindiğim gibi,
Microsoft son dönemde IDE deneyimine baya yatırım yapıyor.
SP GO’nun da bu yolculuğa en kısa zamanda katılması lazım.
Sıkça Sorulan Sorular
SPGO ile klasik PGO arasında ne fark var?
Klasik PGO’da özel bir instrumented binary derliyorsunuz, sonra o binary’yi çalıştırarak profil topluyorsunuz (buna dikkat edin). SPGO işe normal release binary’nizden sampling yaparak profil topluyor. Yanı aslında SPGO çok daha düşük overhead’e sahip — production ortamında çalışabiliyor ve build pipeline’a entegre etmesi de çok daha kolay.
Küçük projeler için SPGO kullanmak mantıklı mı?
Açıkçası, Açıkçası, genelde hayır. Projeniz birkaç on bin satırın altındaysa önce /O2 /GL /LTCG gibi temel iyileştirme flag’lerini deneyin. Hani profil toplama, representative workload otomasyonu, iki aşamalı build derken SPGO’nun getirdiği ekstra altyapı maliyeti küçük projelerde ROI’yi ciddi anlamda bozuyor.
Her uygulamada %20 performans artışı bekleyebilir mıyım?
Net bir şekilde hayır. Photoshop’taki %20 rakamı biraz özel bir durum — hem devasa bir kod tabanı var hem de CPU-bound hot path’ler çok yoğun. Bence bu rakamı baz almak yanıltıcı olabilir. Mesela GPU ağırlıklı çalışan (belki yanılıyorum ama) uygulamalarda kazanım çok daha düşük kalabiliyor. Genel beklenti %5-15 aralığında, ama profil olmadan tahmin yapmak gerçekten riskli — dürüst olayım, biraz hayal kırıklığı —
SPGO için Visual Studio 2026 şart mı?
SPGO desteği MSVC’nın son sürümlerinde mevcut. Tecrübeme göre flag’ler. Workflow sürümler arasında değişebildiğinden, tam toolchain detayları için Microsoft’un resmî dokümantasyonunu takip etmenizi öneririm.
Photoshop’un ARM64 sürümünde kazanım neden daha az öldü?
İlginç olan şu ki, ARM64 mimarisi zaten daha fazla register sunuyor. Instruction set’i daha düzenli — bu yüzden baseline kod kalitesi baştan daha yüksek. x64 mimarisinde işe optimizasyon için çok daha fazla manevra alanı kalıyor. Yanı aslında %13 ARM64 kazanımı hiç de kötü değil bence — bu rakam, baseline’ın. Oldukça iyi olduğunu gösteriyor.
Kaynaklar ve İleri Okuma
Ne yalan söyleyeyim, Microsoft C++ Team Blog: Boosting Adobe Photoshop’s Performance with MSVC and SPGO
Microsoft Learn: Profile-Guided Optimizations Resmî Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder