GitHub Copilot Build Performance: Proje Bazlı Analiz Geldi
Araya gireyim: Açık söyleyeyim: Visual Studio’da büyük bir C++ solution’ı build ederken sabrımın taşmadığı gün sayısı azdır. Hele Copilot’a “şu build’i hızlandır” dediğinizde, full solution trace bitene kadar gidip kahve değil, neredeyse Türk kahvesi pişirip içip dönüyordunuz. Neyse, o dert artık biraz hafifliyor (en azından benim deneyimim böyle)
Microsoft, GitHub Copilot Build Performance for Windows’a sonunda project-specific build desteği ekledi. Yanı artık tüm solution’ı baştan sona taramadan, sadece tek bir MSBuild projesi ya da CMake target’ı için analiz alabiliyorsunuz. Visual Studio Insiders’ın son sürümünde var. Oyun stüdyoları ve enterprise monorepo’larla uğraşan ekipler için küçük görünüyor ama baya iş görüyor.
Önce Şunu Soralım: Neden Önemli?
Garip gelecek ama, Bir Unreal Engine tabanlı proje düşünün. 800+ modül, binlerce header, derleme süresi de rahatlıkla 25-40 dakika. Sız sadece tek bir gameplay modülünün build performansını iyileştirmek istiyorsunuz. Eski düzende Copilot’a soru sorunca agent gidiyor, full solution trace alıyor, geri geliyor (kendi tecrübem). Bu arada sız Slack’e geçmişsinizdir bile, başka bir bug’a dalmışsınızdır, hatta belki öğle yemeğine çıkmışsınızdır.
Sonuç? Akış kopuyor. Geliştiricinin “hadi şu performans işine bakayım” motivasyonu da trace bittiğinde çoğu zaman sönmüş oluyor.
Size bir şey söyleyeyim, Microsoft ekibi Public Preview döneminde aynı geri bildirimi defalarca almış: “Tek bir projeyi analiz etmeme izin verin yeter.” Bu güncelleme tam olarak ona cevap veriyor. Agent’ın zekâsı değişmedi; sadece build adımının kapsamı daraldı. Analiz modeli yine aynı yerde dürüyor; pahalı header’lar, uzun süren fonksiyon üretimleri, ağır template instantiation’lar — hepsi rapora giriyor.
“Build trace 30 dakika sürerse, geliştirici 31. dakikada zaten başka bir göreve geçmiş olur. Bu özelliğin asıl kazandırdığı şey zaman değil, odak.”
Üç Farklı Yoldan Başlatabiliyorsunuz
Microsoft giriş noktasını üçe bölmüş — bence iyi etmiş. Çünkü her geliştiricinin alışkanlığı farklı. Ben mesela Solution Explorer’a pek uğramam; her şeyi Copilot Chat’ten çözmeye çalışırım. Başka biri sağ tık menüsünden gider. Üçü de aynı analiz pipeline’ına bağlanıyor sonuçta.
1. Solution Explorer’da Sağ Tık
En kısa yol bu. Solution Explorer’da herhangi bir projeye sağ tıklayın, Run Build Insights > Improve Build Performance deyin. Copilot Chat penceresi seçtiğiniz projeyle önceden doldurulmuş şekilde açılıyor. Tek kelime yazmanıza gerek yok.
2. Build Menüsünden
İnanın, Solution Explorer’dan bir proje seçtikten sonra üst menüde Build > Run Build Insights on Selection > Improve Build Performance seçeneği çıkıyor. Keyboard-driven çalışanlar için fena değil; menü kısayollarına alışkınsanız elinizi pek kaldırmadan ilerliyorsunuz.
3. Doğrudan Copilot Chat’ten
GitHub Copilot Chat panelini açın, agent combo box’ından @BuildPerfCpp responder’ını seçin. Sonra şöyle yazın:
@BuildPerfCpp Help me improve build performance for MyGameplayModule
MyGameplayModule yerine kendi MSBuild projenizin ya da CMake target’ınızın adını yazıyorsunuz. Bu yöntemin güzel tarafı şu: Birden fazla projeyi sırayla analiz etmek istediğinizde sürekli menüye gidip gelmiyorsunuz; aynı chat içinde devam ediyorsunuz.
Eski Yollar da Dürüyor
İlginç olan şu ki, Eğer full-solution analizine ihtiyacınız varsa eski giriş noktaları hâlâ çalışıyor. Build > Run Build Insights on Solution seçeneği yerinde dürüyor. Yanı Microsoft yeni özelliği eklerken eskisini kırmamış; iyi olmuş bu arada, çünkü böyle güncellemelerde yarım gün “bu niye bozuldu?” diye kaybolmak insanı yoruyor. Daha fazla bilgi için github konusundaki yazımız yazımıza bakabilirsiniz.
Peki Hangi Senaryoda Hangisi?
Lafı gevelemeden pratik tarafa geçelim: Ne zaman full-solution kullanmalı, ne zaman project-specific? Aşağıdaki tablo yıllardır kafamda dönen karar matrisinin yazıya dökülmüş hali gibi düşünün; alın, bir kenarda dursun: geldi konusundaki yazımız yazımızda bu konuya da değinmiştik.
| Senaryo | Tavsiye Edilen Yaklaşım | Neden? |
|---|---|---|
| Sadece tek modülün PCH’ını optimize ediyorum | Project-specific | Diğer projeler bu işle alakalı değil |
| Tüm solution’da include hijyeni yapacağım | Full-solution | Bazı bağımlılıklar zincir gibi her yere yayılıyor |
| CI’da 5 dakika kazanmak istiyorum | Full-solution | Bottleneck çoğu zaman linker/IPO katmanında oluyor |
| Küçük bir feature branch üzerinde test yapıyorum | Project-specific | Daha hızlı geri bildirım lazım oluyor |
| Game studio içinde tek bir gameplay system ile uğraşıyorum | Project-specific | Aksi hâlde trace süresi uzayıp gidiyor; bazen 40 dk’dan üç dk’ya düşüyor |
Neden Hele bir de Bizim Tarafa Dokunuyor?
Açık konuşayım: Türkiye’de C++ ile ciddi kurumsal kod yazan ekip sayısı çok yüksek değil gibi geliyor bana. Genelde oyun stüdyoları, gömülü sistem firmaları, biraz finans (özellikle HFT ve ödeme yönlendirme tarafı) ve savunma sanayii öne çıkıyor. Bu özelliğin bizim ekosistemde en çok karşılık bulacağı yer işe bence oyun stüdyoları.
Neyse uzatmayayım ama geçen yıl İstanbul’da bir mobil oyun şirketinde danışmanlık yaparken — şirket ismi vermeyeyim — şunu gördüm: build süreleri yüzünden takım Maç mini farm’a yatırım yapmayı bile düşünüyordu (bu beni çok şaşırttı). Halbuki sorun donanım değildi; PCH yapısı dağılmıştı, header dependency’ler kontrolden çıkmıştı. O dönemde Build Insights kullansaydık ve project-specific moda geçebilseydik, en az 3-4 günlük profilleme işini yarım günde toparlardık gibi geliyor.
Enterprise tarafında işe iş biraz değişiyor. Mesela bankada eski bir C++ trading sistemi varsa ekip çoğu zaman Visual Studio yerine kendi cross-platform build sistemlerini (Bazel, custom CMake) kullanıyor olabilir.
Bu durumda Copilot Build Performance ne kadar yardım eder? Biraz tartışmalı açıkçası.
Çünkü trace MSBuild ve CMake target’ları üzerinden çalışıyor; özel build sistemlerinde entegrasyon genelde pürüzsüz olmuyor.
Maliyet ve Verim Tarafına Bakınca Ne Çıkıyor?
Tam burada TL hesabına girelim bari. GitHub Copilot Business lisansı kişi başı aylık yaklaşık 19 USD civarında dolaşıyor.
Kur farkını ekleyince kabaca 700-800 TL/ay/kişi ediyor.
10 kişilik bir C++ ekibi için aylık toplam da yaklaşık 8 bin TL civarı oluyor.
Kısa bir not düşeyim buraya. .NET 10 ile WebAssembly Hızlanınca Copilot Studio’da Neler Değişti? yazımızda bu konuya da değinmiştik.
💡 Bilgi: Visual Studio Insiders kanalında mevcut.
💡 Bilgi: Production’da kullanmak istiyorsanız GA sürümünü beklemek daha güvenli olur.
💡 Bilgi: Insiders kanalında ara sıra regresyon görebiliyorsunuz.
}
`
Sıkça Sorulan Sorular
Project-specific build özelliği ücretli mi?
Özelliğin kendisi ücretsiz aslında, ama kullanabilmek için aktif bir GitHub Copilot aboneliğiniz olması gerekiyor. Individual veya Business planı ikisi de işe yarıyor. Şirket lisansıyla geliyorsanız IT’ye sorun, hani bu agent’ın erişime açık olup olmadığını bir teyit edin.
CMake target’ları MSBuild projeleri kadar iyi destekleniyor mu?
Kısaca: hayır, henüz değil. MSBuild tarafı çok daha olgun yanı. CMake’de özellikle preset ve multi-config generator senaryolarında agent’ın target’ı zaman zaman yanlış yorumladığını gördüm. Single-config bir CMake yapısında bence sorun çıkmıyor, ama complex setup’larda gerçekten dikkatli olun.
Şimdi gelelim işin can alıcı noktasına. Mailbox Import/Export Graph API’leri GA: EWS’in Sonu Geldi yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Kubernetes v1.36 Pod-Level In-Place Resize: Beta’ya Yükseldi yazımıza da göz atmanızı tavsiye ederim.
Visual Studio Insiders’ı production’da kullanmak güvenli mi?
Açıkçası genel tavsiyem hayır. Insiders kanalı pre-release sürümler içeriyor, regresyon ve crash riski var. Yan yana kurulum yapıp sadece deneme amaçlı kullanın. Asıl iş akışınız stable VS sürümünde kalsın — bu özellik GA olduğunda zaten resmî sürüme inecek.
Trace verisi Microsoft’a gönderiliyor mu?
Copilot agent’ları doğası gereği context’i bulut tarafındaki modele iletiyor. Build Insights trace dosyasının ne kadarının agent’a açıldığı konusunda Microsoft’un detaylı bir whitepaper yayınlaması gerekiyor aslında (bizzat test ettim). Hassas IP içeren projelerde, yanı en azından şimdilik, full-solution yerine project-specific kullanmak görüş alanını daraltıyor — bence bu doğal bir koruma yöntemi olarak işe yarıyor.
Ve işler burada ilginçleşiyor.
Build süremin gerçekten düşeceğini nasıl ölçerim?
En basit yol optimizasyon öncesi ve sonrası clean build sürelerini Stopwatch ile karşılaştırmak. Daha bilimsel olmak istiyorsanız Build Insights’ın kendi ETL trace dosyalarını kullanın, WPA (Windows Performance Analyzer) ile inceleyin. Tek ölçümle yetinmeyin sakın — tecrübeme göre disk cache etkisi sonuçları kolayca yanıltabiliyor, en az 3-5 kez çalıştırıp ortalamayı alın.
Kaynaklar ve İleri Okuma
Microsoft C++ Team Blog — Project-Specific Build Optimizations with GitHub Copilot
Kendi deneyimimden konuşuyorum, Microsoft Learn — C++ Build Insights Resmî Dokümantasyonu
İtiraf edeyim, GitHub Copilot Resmî Sayfası ve Lisanslama Detayları
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.
3 comments