Bakın şimdi, C++ tarafında çalışanlar bilir — büyük bir solution’ı baştan sona derlemek pek keyifli ölmüyor. Hele bunu sadece “tek bir projedeki yavaşlığı bulmak için” yapıyorsanız… Açık konuşayım, ben olsam tabımı kapatır kahveye kaçardım. Geçen hafta bir oyun stüdyosu müşterimizde tam da bunu gördüm.
Neyse, asıl mesele burada. Microsoft, Visual Studio Insiders sürümünde GitHub Copilot Build Performance aracına yeni bir şey ekledi: proje bazlı build analizi. Yanı artık büyük çoğunluk solution’ı yeniden derlemeniz gerekmiyor. İlgilendiğiniz tek bir MSBuild projesini ya da CMake target’ını seçiyorsunuz, Copilot agent’ı da sadece önü didikliyor (evet, lafı biraz böyle söyleyeyim) — bence çok yerinde bir karar —. Kulağa basit geliyor, ama büyük kod tabanlarıyla uğraşan ekipler için baya iş görüyor (inanın bana)
Şimdi gelelim işin can alıcı noktasına.
Niye Bu Özellik Önemli? Sahadaki Hikâye
Açıkçası, Bir önceki sürümde, yanı Public Preview tarafında, agent tüm solution’ı build ediyordu. Trace topluyor, sonra analiz ediyor, en son da önerileri çıkarıyordu (kendi tecrübem). Güzel fikir. Ama bir sıkıntı var: 200+ projelik bir Unreal Engine fork’unda ya da bankacılık tarafında dev bir monorepo’da full build deyince iş uzuyor, 40 dakika gidiyor bazen 1 saate yaklaşıyor, geliştirici de doğal olarak başka sekmeye kayıyor.
Dürüst olmak gerekirse, Microsoft ekibi bunu “adoption blocker” diye tarif etmiş; yanı aracın yaygınlaşmasının önüne takılan ana duvar. Açık konuşayım, bence yerinde tespit. Logosoft’ta bir oyun şirketiyle çalışırken aynı cümleyi birebir duymuştum: “Aşkın, araç güzel de, kim 45 dakika bekleyecek bunu?” İşte mesele bu. O zaman elimizdeki tek yol /Bt+ flag’iyle elle ETW trace toplamaktı; şimdi en azından kapsam daraltılabiliyor. Evet, fark ciddi.
Durun, bir saniye.
Önemli not: Bu yenilik analiz modelini değiştirmiyor. Sadece build adımının kapsamını daraltıyor. Yanı Copilot’un zekâsı aynı; pahalı header’ları, uzun süren function generation’ları, maliyetli template instantiation’ları yine aynı şekilde tespit ediyor.
Üç Farklı Giriş Yolu
Şöyle söyleyeyim, Visual Studio’da bu özelliğe üç ayrı kapıdan giriyorsunuz. Hepsi aynı analiz pipeline’ına bağlanıyor, yanı sonuç değişmiyor; sadece işi başlatma şekli farklı oluyor. Kulağa ufak bir detay gıbı geliyor ama bazen tam da o ufak detay, akşamı kurtarıyor.
1. Solution Explorer’dan Sağ Tık
Bir şey dikkatimi çekti: En pratik yol bu, açık konuşayım. Solution Explorer’da herhangi bir projeye sağ tıklıyorsunuz, sonra “Run Build Insights > Improve Build Performance” seçeneğine basıyorsunuz. Copilot Chat penceresi açılıyor ve prompt da zaten doldurulmuş hâlde geliyor (ciddiyim). Sizden ekstra bir şey istemiyor. Hatta yeni başlayan biri için iyi tarafı şu: ezber yok, dolaşma yok, uğraşma yok.
Ve işler burada ilginçleşiyor.
2. Build Menüsünden Seçim
Projeyi Solution Explorer’da seçtikten sonra üstteki Build menüsüne gidiyorsunuz. Orada “Build > Run Build Insights on Selection > Improve Build Performance” diye bir seçenek çıkıyor, biraz uzun isimli ama işini yapıyor. Aynı mekanizma çalışıyor aslında; sadece menüyle ilerlemeyi sevenler için başka bir giriş noktası var. Peki neden böyle iki yol koymuşlar? Bence bayağı alışkanlık meselesi.
3. Doğrudan Copilot Chat’ten
Bu benim en sevdiğim yol, çünkü hızlı ve lafı uzatmıyor. Copilot Chat’i açıyorsunuz, agent combo box’tan @BuildPerfCpp seçiyorsunuz, sonra şunu yazıyorsunuz: biraz kısa, biraz net, tam aradığım tarzda.
@BuildPerfCpp Help me improve build performance for MyGameEngineCore“MyGameEngineCore” yerine kendi MSBuild proje adınızı ya da CMake target adınızı yazıyorsunuz. Hepsi bu kadar. Komut satırıyla haşır neşir olanlar için baya iş gören bir deneyim olmuş; hatta şaşırdım açıkçası, bu kadar direkt olmasını beklemiyordum.
Eski Yöntem Hâlâ Duruyor mu?
Küçük bir detay: Evet, duruyor. Tüm solution’ı analiz etmek istiyorsanız Build menüsündeki “Run Build Insights on Solution” seçeneği hâlâ yerinde, yanı proje bazlı analiz onun yerine geçmiş değil; daha çok yanına eklenen başka bir yol gıbı düşünün. Hangisini ne zaman kullanacağınıza gelince, işin özü biraz şöyle: tek bir modülde yavaşlık görüyorsanız proje bazlı analiz daha az gürültüyle ilerliyor, ama genel build akışını anlamaya çalışıyorsanız solution geneli daha mantıklı kalıyor. Burada, peki neden? Çünkü cross-project bağımlılıklar orada daha net görünüyor.
| Senaryo | Önerilen Yol | Neden? |
|---|---|---|
| Tek bir modülde yavaşlık var | Proje bazlı analiz | Hızlı, odaklı, az gürültü |
| Genel bir build profili istiyorum | Solution geneli | Cross-project bağımlılıklar görünür |
| CI pipeline’ında darboğaz arıyorsunuz | Solution geneli | Gerçek build davranışını yansıtır |
| Yeni bir refactor sonrası kontrol | Proje bazlı | Sadece etkilenen alana bakar |
| İlk kez aracı deniyorsunuz | Proje bazlı (küçük proje) | Öğrenme eğrisi düşük |
Türkiye’deki Ekipler Açısından Değerlendirelim
Şunu söyleyeyim, Bak şimdi, Türkiye’de C++ ile ciddi ciddi uğraşan ekipler aslında çok kalabalık değil. Oyun stüdyoları var, mesela TaleWorlds, Peak Games tarafındaki bazı ekipler, Masomo gıbı ekipler; bir de gömülü sistem çalışan firmalar, savunma sanayii tarafı. Finans/HFT ekiplerinin bir kısmı. Bunların çoğu Visual Studio kullanıyor, Linux’a kayanlar da var ama Windows hâlâ ağır basıyor. Uzun lafın kısası, masa üstünde bildiğimiz düzen kolay kolay bırakılmıyor. Bu konuyla ilgili Copilot Agent Evaluations: Ajan Kalitesini Ölçen CLI Geldi yazımıza da göz atmanızı tavsiye ederim.
Kurumsal müşterilerimde gördüğüm şey şu: bu tıp araçların benimsenmesi Türkiye’de biraz ağır ilerliyor. Sebep tek değil; kimi GitHub Copilot lisans bütçesine takılıyor, kimi Insiders sürümünü kurumsal politika yüzünden açamıyor, kimi de “biz. vcperf kullanıyoruz, niye değiştirelim” diyor. Açık konuşayım, hepsi biraz haklı biraz da inatçı. Çünkü vcperf ile WPA ikilisi baya iş görüyor ama öğrenmesi kolay değil; Copilot’un yaptığı şey de tam burada devreye giriyor (trace yorumunu modele bıraktırıyor), yanı yükü biraz omuzdan alıyor. Evet.
Pratikte Ne Buluyor Bu Agent?
Geçen ay bir oyun motoru projesinde denedik. Renderer tarafını tek başına kurcalayınca agent birkaç şeyi hemen yakaladı, hatta biri öyle yan taraftan gelmedi; direkt compile time’a abanıyordu.
- Header bloat:
<windows.h>bir utility header üzerinden 47 farklı.cpp dosyasına sızmış. Tek başına compile time’ın %18’ını yiyordu. - Template instantiation: Bir generic container, debug build’de 3.2 saniye instantiation alıyordu. Release’de 0.4 saniye. Tipik debug-only şişme.
- Function generation: Aşırı inline edilmiş bir matematik kütüphanesi compiler’ı zorluyordu — agent
__forceinlineyerine seçici inline önerdi. - PCH eksikliği: Precompiled header kullanılmıyordu. Bu modülde PCH önerisi tek başına %30 hızlanma getirdi.
Yanı agent bayağı somut çıktı veriyor. Ama dür, iş burada bitmiyor; her önerisini körlemesine uygulamak da pek akıllıca değil, çünkü bir keresinde önerdiği bir #include kaldırma işlemi unity build dışında compile error veriyordu. Bağlamı %100 bilmiyor, o yüzden doğrulama hâlâ sizde kalıyor.
Evet.
Bakın, açık konuşayım, ben bu tıp araçlarda en çok şu kısmı seviyorum: lafı dolandırmadan nerede zaman yediğini gösterebiliyor,. Aynı anda biraz da “bak ben ipucu verdim, gerisini sen çöz” havasında kalıyor. Siz ne dersiniz?
Küçük Ekip vs Büyük Kurum: Hangisine Ne Yarar?
Açık konuşayım, eğer 5 kişilik bir indie oyun ekibiyseniz, Copilot Build Performance için koşturmaya gerek yok. Profiler kullanmayı öğrenin; /d2cgsummary ve /Bt+ flag’lerine bakın, işin omurgası zaten orada. Aylık Copilot Pro ücreti küçük ekipte biraz can sıkar. Evet.
Bakın, Bak şimdi, 50+ developer’lı kurumsal bir yapıda tablo bir anda değişiyor. Her geliştiricinin günde 30-40 dakikasını build bekleyerek harcadığını düşünün; kulağa ufak geliyor ama ay sonu adam-saat hesabı yapılınca rakamlar şişiyor (hele dağıtık ekiplerde daha da can yakıyor). Bir telekomda yaptığımız ölçümde bu kayıp 850 saat/ay civarındaydı, yanı lisans maliyetiyle kıyaslayınca konu baya farklı bir yere gidiyor. Daha açık söyleyeyim, peki neden? Çünkü orada ROI kendini saklamıyor, direkt masanın üstüne çıkıyor.
İlk Adım Olarak Ne Yapın?
Pratik bir yol bırakayım, çünkü konu biraz dağılmaya çok müsait. Önce bunu kurcalayın. Handoff Orchestration: Ajanlar Birbirine Topu Atınca Ne yazımızda bu konuya da değinmiştik. Kubernetes v1.36 Declarative Validation: GA’ya Ulaştı yazımızda bu konuya da değinmiştik.
- Visual Studio Insiders’ı kurun (yan yana stabil sürümle birlikte çalışıyor, ana kurulumunuzu bozmaz). (bu kritik)
- GitHub Copilot eklentisini aktive edin — Pro veya Business lisansı gerekiyor.
- En yavaş build aldığınız projeyi seçin. Her geliştiricinin böyle bir projesi vardır, biliyorum. (bence en önemlisi)
- Sağ tık > Run Build Insights > Improve Build Performance. — bunu es geçmeyin
- Çıkan önerileri tek tek değerlendirin — hepsini uygulamayın, mantıklı olanları seçin. (bence en önemlisi)
- Değişiklikten sonra tekrar ölçüm yapın. Bu adımı atlamayın, yoksa neyin işe yaradığını bilemezsiniz.
Evet. Burada kritik nokta şu: her öneri iyi diye alınmaz, bazen biri baya iş görüyor, öbürü işe sadece ekran kalabalığı yapıyor; ben olsam önce küçük dokunuşlarla giderim, sonra ölçerim, sonra gerekirse geri dönerim. Neyse uzatmayalım.
Bir dakika — bununla bitmedi.
Bu arada, build performansı agent’ı dışında Visual Studio 2026 Nişan: Copilot Agent’ları Devreye Girdi yazımda diğer agent’lardan da bahsetmiştim, ona da göz atmak isteyebilirsiniz. Bir de daha geniş Copilot ekosistemini merak edenler için GitHub Copilot CLI: Kurumsal Plugin Yönetimi Public yazısı var. Hani şu bağlantılar var ya, onları da boş geçmeyin; çünkü bazen asıl fikir yan yazıda saklı oluyor. Peki neden? Çünkü aynı aracın farklı parçaları birbirini tamamlıyor gıbı duruyor, ama açık konuşayım, bazen biri diğerinden daha çok iş çıkarıyor.
Tam da öyle. Daha fazla bilgi için Azure SQL’de AI_GENERATE_EMBEDDINGS GA Oldu: Saha Notları yazımıza bakabilirsiniz.
Eksikler ve Beklediğim Şeyler
Şimdi işin diğer tarafına geçelim. Kağıt üstünde güzel duruyor, evet, ama birkaç yerde insanın kaşı kalkıyor. Kubernetes v1.36 DRA: Yeni Sürücüler ve Sahadan Notlar yazımızda bu konuya da değinmiştik.
Birinçisi: CMake desteği, en azından şimdilik, MSBuild tarafı kadar oturmuş değil. Büyük CMake projelerinde target seçimi bazen garip davranıyor, bir bakıyorsun doğru hedefi buluyor, bir bakıyorsun eline yüzüne bulaştırıyor; Microsoft’un bu kısmı biraz daha eşitlemesi gerekiyor.
İkincisi: Agent önerilerinde “before/after” kıyasını otomatik vermiyor. Yanı öneriyi uyguluyorsunuz, sonra “tamam da ne değişti?” diye tekrar ölçüm yapmanız lazım. Açık konuşayım, burada küçük bir karşılaştırma ekranı olsa baya iş görür.
Üçüncüsü: Cross-project öneriler proje bazlı modda biraz sönük kalıyor. Sorunun kaynağı çoğu zaman baktığınız projede değil de ona bağlı başka bir yerde çıkabiliyor; agent da doğal olarak dar alanda kalınca bunu kaçırabiliyor —. Hani siz de scope’u bilerek daraltmış oluyorsunuz.
Garip gelecek ama, Peki bu gerçekten eksik mi? Hmm, tam emin değilim. Bence üçüncü madde aslında tasarımsal bir tercih gıbı duruyor, (yanlış duymadınız) — dürüst olayım, biraz hayal kırıklığı —. Sistem “sadece bu projeye bak” denince önü ciddiye alıyor; yine de ufak bir uyarı fena olmazdı: “Bu yavaşlığın kaynağı X projesinde olabilir, oraya da göz atın” gıbı.
Evet.
Sıkça Sorulan Sorular
Ayrı bir lisans almam gerekiyor mu?
Hayır, elinizdeki GitHub Copilot lisansı yeterli. Pro, Business veya Enterprise — hangisi olursa olsun çalışıyor. Ayrıca bir “Build Performance” SKU’su falan yok. Şu an için tek şart Visual Studio Insiders sürümünü kullanmak.
Linux veya macOS’ta da çalışıyor mu?
Açıkçası şu an sadece Windows’ta, Visual Studio Insiders üzerinde çalışıyor. Linux kullanıyorsanız clang -ftime-trace + ClangBuildAnalyzer ikilisini öneririm — bence gayet iyi bir alternatif. macOS tarafında işe Xcode’un kendi build timeline’ı işinizi görür zaten.
Agent’ın önerilerini direkt uygulayabilir mıyım?
Otomatik kabul etmeyin, gerçekten. Her öneriyi ayrı bir branch’te deneyin, birim testlerini koşturun, ondan sonra merge edin (şaşırtıcı ama gerçek). Mesela #include kaldırma önerileri, unity build’lerde veya farklı platform build’lerinde beklenmedik kırılmalara yol açabiliyor (bizzat test ettim). Tecrübeme göre manuel doğrulama bu adımda kesinlikle şart.
CMake target adını nasıl bulabilirim?
CMakeLists.txt içindeki add_library() veya add_executable() komutlarının ilk parametresi target adıdır. Ayrıca Visual Studio’nün CMake Targets View’ından da görebilirsiniz. Yanı aslında çok zor değil,. Bu ne anlama geliyor? Şunu söyleyeyim: çok hedefli projelerde target adı dosya adıyla aynı olmayabiliyor — o noktada dikkatli olun (inanın bana)
Build Insights ile Copilot Build Performance arasında ne fark var?
Build Insights, Visual Studio’nün yıllardır var olan trace toplama ve görselleştirme özelliği. Copilot Build Performance işe bu trace’leri bir AI agent’ına yorumlatıyor ve eyleme dönük öneriler üretiyor. Bu ne anlama geliyor? Hani biri ham veri sunuyor, diğeri o veriyi alıp anlamlı bir çıktıya dönüştürüyor — bu kadar basit aslında.
Kaynaklar ve İleri Okuma
Project-Specific Build Optimizations with GitHub Copilot — Microsoft C++ Team Blog (yanlış duymadınız)
C++ Build Insights Resmî Dokümantasyonu
Visual Studio Insiders İndirme Sayfası (inanın bana)
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.
