Çift çekirdekli 2GHz, 2G Ram makinelerde 20 dakikadan fazla sürebilen çok yavaş derleme süreleri alıyoruz.

Bunun çoğu, 70'den fazla projeye ulaşan çözümümüzün boyutundan ve çok sayıda dosyanız olduğunda başlı başına bir dar boğaz olan VSS'den kaynaklanmaktadır. (VSS'yi değiştirmek maalesef bir seçenek değil, bu yüzden bunun bir VSS bashına inmesini istemiyorum)

Birleştirme projelerine bakıyoruz. Ayrıca, kaygıların daha fazla ayrılması ve uygulamanın her öğesi için daha hızlı derleme süreleri elde etmek için birden fazla çözüme sahip olmayı da arıyoruz. Görebildiğim bu şey, biz işleri senkronize etmeye çalışırken bir DLL cehennemi olacak.

Diğer takımların bu ölçeklendirme sorunuyla nasıl başa çıktıklarını merak ediyorum, kod tabanınız kritik bir kütleye ulaştığında, durum çubuğunun derleme mesajlarını iletmesini izleyerek yarım gün harcadığınız zaman ne yaparsınız?

GÜNCELLEME Bunun bir C # çözümü olduğundan bahsetmeyi ihmal ettim. Tüm C ++ önerileri için teşekkürler, ancak başlıklar hakkında endişelenmem gerekmeyeli birkaç yıl oldu.

DÜZENLE:

Şimdiye kadar yardımcı olan güzel öneriler (aşağıda başka güzel öneriler olmadığını söylememek, sadece yardımcı olan şey)

• Yeni 3GHz dizüstü bilgisayar - kayıp kullanımın gücü, yönetime sızlanırken harikalar yaratıyor
• Derleme sırasında Anti Virüsü devre dışı bırakın
• Derleme sırasında VSS'den (aslında ağ) 'bağlantının kesilmesi' - VS-VSS entegrasyonunu tamamen kaldırmamızı ve VSS kullanıcı arayüzünü kullanmaya devam etmemizi sağlayabilirim

Yine de bir derlemede rip-snorting değil, ama her parçası yardımcı oluyor.

Orion, jenerik ilaçların da bir oyun oynayabileceğinden bahsetti. Testlerime göre minimum performans vuruşu var gibi görünüyor, ancak emin olmak için yeterince yüksek değil - disk etkinliği nedeniyle derleme süreleri tutarsız olabilir. Zaman sınırlamaları nedeniyle, testlerim canlı sistemde göründüğü kadar çok Jenerik veya kod içermiyordu, bu yüzden birikebilir. Sadece derleme zamanı performansı için kullanılması gereken yerde jenerik kullanmaktan kaçınmam

Pratik Çözüm

Yeni çözümlerde yeni uygulama alanları oluşturma, en son dll'leri gerektiği gibi içe aktarma, onlardan memnun kaldığımızda bunları daha büyük çözüme entegre etme pratiğini test ediyoruz.

Bunları, sadece üzerinde çalışmamız gereken alanları kapsayan geçici çözümler oluşturarak ve kodu yeniden entegre ettikten sonra bunları atarak mevcut koda da aynısını yapabiliriz. Geliştirme sırasında Rip Van Winkle gibi deneyimler yaşamamakla kazandığımız zamana karşı bu kodu yeniden entegre etmek için gereken zamanı tartmamız gerekiyor.

Chromium.org ekibi , derlemeyi hızlandırmak için birkaç seçenek listeledi (bu noktada sayfanın yaklaşık yarısına kadar):

Azalan hızlanma sırasında:

• Microsoft düzeltmesi 935225'i yükleyin .
• Microsoft düzeltmesi 947315'i yükleyin .
• Gerçek bir çok çekirdekli işlemci kullanın (yani bir Intel Core Duo 2; Pentium 4 HT değil).
• 3 paralel yapı kullanın. Visual Studio 2005'te, seçeneği Araçlar> Seçenekler ...> Projeler ve Çözümler> Oluştur ve Çalıştır> maksimum paralel proje derlemesi sayısı içinde bulabilirsiniz .
• .İlk, .pdb, .cc, .h dosyaları için anti-virüs yazılımınızı devre dışı bırakın ve yalnızca değişiklik yapıldığında virüsleri kontrol edin . Kaynaklarınızın bulunduğu dizini taramayı devre dışı bırakın. Aptalca bir şey yapma.
• Chromium kodunu ikinci bir sabit sürücüde depolayın ve oluşturun. Derlemeyi gerçekten hızlandırmaz, ancak en azından bilgisayarınız, gclient senkronizasyonu veya derleme yaptığınızda yanıt vermeye devam edecektir.
• Sabit sürücünüzü düzenli olarak birleştirin.
• Sanal belleği devre dışı bırakın.

Tek bir çözümde yaklaşık 100 projemiz ve yalnızca saniyeler süren geliştirme süremiz var :)

Yerel geliştirme yapıları Project referencesiçin DLL references, istenmeyen projeleri değiştiren ve kaldıran bir Visual Studio Eklentisi oluşturduk (ve elbette bunları geri değiştirme seçeneği).

• Tüm çözümümüzü bir kez oluşturun
• Şu anda üzerinde çalışmadığımız projeleri kaldırın ve tüm proje referanslarını DLL referanslarıyla değiştirin.
• Teslim etmeden önce tüm başvuruları DLL'den proje başvurularına geri değiştirin.

Bir seferde yalnızca birkaç proje üzerinde çalışırken, derlemelerimiz artık yalnızca saniyeler sürüyor. Hata ayıklama DLL'lerine bağlandığı için ek projelerde hala hata ayıklayabiliriz. Aracın çok sayıda değişiklik yapması genellikle 10-30 saniye sürer, ancak bunu çok sık yapmanız gerekmez.

Mayıs 2015 Güncellemesi

Yaptığım anlaşma (aşağıdaki yorumlarda), yeterince ilgi görürse eklentiyi Açık Kaynak olarak yayınlayacaktım . 4 yıl sonra yalnızca 44 oy aldı (ve Visual Studio'nun artık iki sonraki sürümü var), bu nedenle şu anda düşük öncelikli bir proje.

21 proje ve 1/2 milyon LOC ile bir çözümde benzer bir sorun yaşadım. En büyük fark, daha hızlı sabit diskler elde etmekti. Performans monitöründen 'Ort. Disk Sırası 'dizüstü bilgisayarda önemli ölçüde yukarı sıçrayarak sabit sürücünün şişe boynu olduğunu gösterir.

İşte toplam yeniden oluşturma süreleri için bazı veriler ...

1) Dizüstü Bilgisayar, Core 2 Duo 2GHz, 5400 RPM Sürücü (önbellekten emin değil. Standart Dell inspiron'du).

Yeniden Oluşturma Süresi = 112 saniye.

2) Masaüstü (standart sorun), Core 2 Duo 2.3Ghz, tek 7200RPM Sürücü 8MB Önbellek.

Yeniden Oluşturma Süresi = 72 saniye.

3) Masaüstü Core 2 Duo 3Ghz, tek 10000 RPM WD Raptor

Yeniden Oluşturma Süresi = 39 saniye.

10.000 RPM sürücü küçümsenemez. Dosya gezgini kullanımının önemli ölçüde daha hızlı olduğu ve dokümantasyonu görüntüleme gibi diğer her şeyin daha hızlı olduğu derlemeler. Kod oluşturma-çalıştırma döngüsünü hızlandırarak büyük bir verimlilik artışıydı.

Şirketlerin geliştirici maaşlarına ne kadar harcadıkları göz önüne alındığında, onları resepsiyonistin kullandığı bilgisayarlarla donatarak satın almayı ne kadar israf edebilecekleri çılgınca .

C # .NET yapıları için .NET Demon'u kullanabilirsiniz . Visual Studio derleme sürecini daha hızlı hale getiren bir üründür.

Bunu yaptığınız değişiklikleri analiz ederek yapar ve yalnızca gerçekten değiştirdiğiniz projeyi ve yaptığınız değişikliklere bağlı olan diğer projeleri inşa eder. Bu, yalnızca dahili kodu değiştirirseniz, yalnızca bir projenin oluşturulması gerektiği anlamına gelir.

Virüsten koruma yazılımınızı kapatın. Derleme zamanına yaş ekler.

Dağıtılmış derlemeyi kullanın. Xoreax IncrediBuild , derleme süresini birkaç dakikaya indirebilir.

Derlemesi genellikle 5-6 saat süren devasa bir C \ C ++ çözümünde kullandım. IncrediBuild bu sürenin 15 dakikaya düşürülmesine yardımcı oldu.

Visual Studio derleme sürenizi birkaç saniyeye düşürme talimatları

Visual Studio maalesef bir derlemenin arabirim değişikliklerini önemsiz kod gövdesi değişikliklerinden ayırt edecek kadar akıllı değil. Bu gerçek, iç içe geçmiş büyük bir çözümle birleştirildiğinde, bazen neredeyse tek bir kod satırını her değiştirdiğinizde mükemmel bir istenmeyen 'tam yapı' fırtınası yaratabilir.

Bunun üstesinden gelmek için bir strateji, otomatik referans ağacı yapılarını devre dışı bırakmaktır. Bunu yapmak için, 'Configuration Manager' (Build / Configuration Manager ... ve ardından Active solution configuration açılır menüsünde 'New' öğesini seçerek Debug yapılandırmasından kopyalayan 'ManualCompile' adlı yeni bir yapı yapılandırması oluşturmak için 'Yeni proje yapılandırmaları oluştur' onay kutusunu işaretlemeyin. Bu yeni derleme yapılandırmasında, hiçbirinin otomatik olarak oluşturulmaması için her projenin işaretini kaldırın. Bu yapılandırmayı 'Kapat'a basarak kaydedin. Bu yeni yapı yapılandırması, çözüm dosyanıza eklenir.

IDE ekranınızın üst kısmındaki yapı yapılandırması açılır menüsü aracılığıyla bir yapı yapılandırmasından diğerine geçiş yapabilirsiniz (genellikle 'Hata Ayıkla' veya 'Yayınla' gösterilen). Etkili bir şekilde bu yeni ManualCompile derleme yapılandırması, 'Çözüm Oluştur' veya 'Çözümü Yeniden Oluştur' için Oluştur menüsü seçeneklerini kullanışsız hale getirecektir. Bu nedenle, ManualCompile modundayken, değiştirmekte olduğunuz her projeyi manuel olarak oluşturmanız gerekir; bu, Çözüm Gezgini'nde etkilenen her projeye sağ tıklayıp ardından 'Oluştur' veya 'Yeniden Oluştur' seçeneğini seçerek yapılabilir. Genel derleme sürelerinizin artık sadece saniye olacağını görmelisiniz.

Bu stratejinin çalışması için, AssemblyInfo ve GlobalAssemblyInfo dosyalarında bulunan VersionNumber'ın geliştiricinin makinesinde statik kalması (tabii ki sürüm derlemeleri sırasında değil) ve DLL'lerinizi imzalamamanız gerekir.

Bu ManualCompile stratejisini kullanmanın olası bir riski, geliştiricinin gerekli projeleri derlemeyi unutması ve hata ayıklayıcıyı başlattıklarında beklenmedik sonuçlar (hata ayıklayıcı eklenemiyor, dosyalar bulunamadı, vb.) Bundan kaçınmak için, daha büyük bir kodlama çabası derlemek için 'Hata Ayıklama' yapı yapılandırmasını kullanmak ve yalnızca birim testi sırasında veya sınırlı kapsamda hızlı değişiklikler yapmak için yalnızca ManualCompile yapı yapılandırmasını kullanmak en iyisidir.

Bu C veya C ++ ise ve önceden derlenmiş üstbilgiler kullanmıyorsanız, kullanmalısınız.

Ana çözümümüzde, bir geliştiricinin ne tür bir makinenin çalıştığına bağlı olarak inşa etmesi yaklaşık 4 ila 6 dakika süren 80'den fazla proje vardı. Bunun çok uzun olduğunu düşündük: Her bir test için FTE'lerinizi gerçekten tüketiyor.

Peki daha hızlı derleme süreleri nasıl elde edilir? Zaten bildiğiniz gibi, yapım süresine gerçekten zarar veren proje sayısıdır. Elbette tüm projelerimizden kurtulup tüm kaynak dosyalarını tek bir dosyaya atmak istemedik. Ancak yine de birleştirebileceğimiz bazı projelerimiz vardı: Çözümdeki her "Depo projesi" kendi birim test projesine sahip olduğundan, tüm birim test projelerini tek bir küresel birim test projesinde birleştirdik. Bu, yaklaşık 12 proje içeren proje sayısını azalttı ve bir şekilde tüm çözümü oluşturmak için% 40 zaman kazandırdı.

Yine de başka bir çözüm düşünüyoruz.

Ayrıca yeni bir projeyle yeni (ikinci) bir çözüm kurmayı denediniz mi? Bu ikinci çözüm, tüm dosyaları çözüm klasörlerini kullanarak birleştirmelidir. Çünkü bu yeni çözümün yalnızca bir projeyle oluşturulma zamanını görünce şaşırabilirsiniz.

Bununla birlikte, iki farklı çözümle çalışmak biraz dikkatli olmayı gerektirecektir. Geliştiriciler aslında ikinci çözümde çalışmaya ve ilkini tamamen ihmal etmeye meyilli olabilirler. 70'den fazla projeyle ilk çözüm, nesne hiyerarşinizi koruyan çözüm olacağından, bu, derleme sunucunuzun tüm birim testlerinizi çalıştırması gereken çözüm olmalıdır. Dolayısıyla, Sürekli Entegrasyon sunucusu ilk proje / çözüm olmalıdır. Nesne hiyerarşinizi korumalısınız, doğru.

Tek bir projeli ikinci çözüm (çok daha hızlı inşa edilecek), tüm geliştiriciler tarafından test ve hata ayıklamanın yapılacağı proje olacaktır. Yine de derleme sunucusuna bakarken onlara dikkat etmelisiniz! Herhangi bir şey kırılırsa düzeltilmesi GEREKİR.

Başvurularınızın doğrudan kitaplık çıktı dizinlerindeki DLL'lere değil Proje başvuruları olduğundan emin olun.

Ayrıca, bunları kesinlikle gerekli olduğu durumlar dışında yerel olarak kopyalamayacak şekilde ayarlayın (Ana EXE projesi).

Bu yanıtı orijinal olarak burada yayınladım: /programming/8440/visual-studio-optimizations#8473 Bu sayfada başka birçok yararlı ipucu bulabilirsiniz.

Visual Studio 2008 kullanıyorsanız, paralel olarak tek bir proje oluşturmak için / MP bayrağını kullanarak derleyebilirsiniz. Bunun Visual Studio 2005'te de belgelenmemiş bir özellik olduğunu okudum, ancak kendimi hiç denemedim.

/ M bayrağını kullanarak birden çok projeyi paralel olarak oluşturabilirsiniz, ancak bu genellikle makinedeki kullanılabilir çekirdek sayısına ayarlanmıştır, ancak bu yalnızca VC ++ için geçerlidir.

Bu sorunun çok eski olduğunu fark ettim, ancak konu bugün hala ilgi çekiyor. Aynı sorun son zamanlarda beni ısırdı ve derleme performansını en çok iyileştiren iki şey (1) derleme için özel (ve hızlı) bir disk kullanmak ve (2) tüm projeler için aynı çıktı klasörünü kullanmak ve projede CopyLocal'ı False olarak ayarlamaktı. Referanslar.

Bazı ek kaynaklar:

• /programming/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

Bazı analiz araçları:

tools-> options-> VC ++ proje ayarları -> Derleme Zamanlaması = Evet, her vcproj için zaman oluşturmanızı söyleyecektir.

/BtHer CPP dosyasının ne kadar harcadığını görmek için derleyici komut satırına anahtar ekleyin

/showIncludesİç içe geçen içeriği (diğer başlık dosyalarını içeren başlık dosyaları) yakalamak için kullanın ve ileriye dönük bildirimleri kullanarak hangi dosyaların çok sayıda GÇ tasarrufu sağlayabileceğini görün.

Bu, bağımlılıkları ve performans domuzlarını ortadan kaldırarak derleyici performansını optimize etmenize yardımcı olacaktır.

Daha hızlı sabit disklere yatırım yapmak için para harcamadan önce, projenizi tamamen bir RAM disk üzerinde oluşturmayı deneyin (yedeklemek için RAM'iniz olduğunu varsayarak). İnternette çeşitli boş RAM disk sürücüleri bulabilirsiniz. RAM diskten daha hızlı olan SSD'ler dahil herhangi bir fiziksel sürücü bulamazsınız.

Benim durumumda, Incredibuild ile 7200 RPM SATA sürücüsünde 6 çekirdekli bir i7 üzerine inşa edilmesi 5 dakika süren bir proje, bir RAM disk kullanılarak yalnızca yaklaşık 15 saniye azaltıldı. Kalıcı depolamaya yeniden kopyalama ihtiyacı ve kayıp çalışma potansiyeli göz önüne alındığında, 15 saniye bir RAM diski kullanmak için yeterli bir teşvik değildir ve muhtemelen yüksek RPM veya SSD sürücüsüne birkaç yüz dolar harcamak için pek bir teşvik değildir.

Küçük kazanç, yapının CPU'ya bağlı olduğunu veya Windows dosya önbelleğe almanın oldukça etkili olduğunu gösterebilir, ancak her iki test de dosyaların önbelleğe alınmadığı bir durumdan yapıldığından, CPU'ya bağlı derlemelere yoğun bir şekilde eğiliyorum.

Derlediğiniz gerçek koda bağlı olarak kilometreniz değişebilir - bu yüzden test etmekten çekinmeyin.

Tam bir derleme yaptıktan sonra derleme dizininiz ne kadar büyük? Varsayılan kuruluma bağlı kalırsanız, oluşturduğunuz her derleme bağımlılıklarının tüm DLL'lerini ve bağımlılıklarının bağımlılıklarını vb. Bin dizinine kopyalayacaktır. Önceki işimde ~ 40 projelik bir çözümle çalışırken meslektaşlarım, derleme sürecinin açık ara en pahalı kısmının bu derlemeleri defalarca kopyalamak olduğunu ve bir derlemenin aynı DLL'lerin gigabaytlarca kopyasını üretebileceğini keşfetti. yeniden.

NDepend'in yazarı Patrick Smacchia'nın, ayrı meclisler olması gerektiğine ve olmaması gerektiğine inandığı bazı yararlı tavsiyeler:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

Temelde bu sorunu çözmenin iki yolu vardır ve her ikisinin de dezavantajları vardır. Birincisi, montaj sayısını azaltmaktır, ki bu açıkça çok fazla iştir. Bir diğeri, yapı dizinlerinizi yeniden yapılandırmaktır, böylece tüm bin klasörleriniz birleştirilir ve projeler bağımlılıklarının DLL'lerini kopyalamaz - bunların hepsi zaten aynı dizinde olduklarından buna gerek yoktur. Bu, bir derleme sırasında oluşturulan ve kopyalanan dosyaların sayısını önemli ölçüde azaltır, ancak kurulumu zor olabilir ve yalnızca paketleme için belirli bir yürütülebilir dosyanın gerektirdiği DLL'leri çıkarırken sizi biraz zorlayabilir.

Belki bazı ortak işlevleri alıp bazı kütüphaneler oluşturun, bu şekilde aynı kaynaklar birden fazla proje için tekrar tekrar derlenmez.

Farklı DLL sürümlerinin karışmasından endişeleniyorsanız, statik kitaplıklar kullanın.

VSS entegrasyonunu kapatın. Bunu kullanma seçeneğiniz olmayabilir, ancak DLL'ler her zaman "yanlışlıkla" yeniden adlandırılırlar ...

Ve önceden derlenmiş başlık ayarlarınızı kesinlikle kontrol edin. Bruce Dawson'ın kılavuzu biraz eski, ancak yine de çok iyi - kontrol edin: http://www.cygnus-software.com/papers/precompiledheaders.html

120 veya daha fazla exes, lib ve dll içeren ve inşa edilmesi uzun süren bir projem var. Bir ana toplu iş dosyasından make dosyaları çağıran bir toplu iş dosyası ağacı kullanıyorum. Geçmişte artımlı (veya mizaçlı mıydı) başlıklardan tuhaf şeylerle ilgili sorunlar yaşadım, bu yüzden şimdi onlardan kaçınıyorum. Nadiren tam bir yapı yapıyorum ve genellikle bir saatlik yürüyüşe çıkarken bunu günün sonuna bırakıyorum (bu yüzden sadece yaklaşık yarım saat sürdüğünü tahmin edebiliyorum). Bu yüzden bunun çalışma ve test için neden uygun olmadığını anlıyorum.

Çalışmak ve test etmek için her uygulama (veya modül veya kitaplık) için tüm hata ayıklama ayarlarına sahip başka bir grup dosyam var - ancak bunlar yine de aynı make dosyalarını çağırıyor. Zaman zaman DEBUG'ı açıp kapatabilirim ve ayrıca yapılara veya yapımlara karar verebilirim veya modülün bağlı olabileceği kitaplıklar da oluşturmak isteyip istemediğimi vb.

Toplu iş dosyası ayrıca tamamlanan sonucu (veya birkaç) test klasörüne kopyalar. Ayarlara bağlı olarak, bu birkaç saniye ile bir dakika arasında tamamlanır (yarım saat demek yerine).

.Rc dosyaları gibi şeyler üzerinde kontrol sahibi olmayı sevdiğim için farklı bir IDE (Zeus) kullandım ve MS derleyicilerini kullanıyor olmama rağmen komut satırından derlemeyi tercih ettim.

İlgilenen varsa bu toplu iş dosyasının bir örneğini göndermekten mutluluk duyarız.

Kaynak dizinlerinizde dosya sistemi indekslemeyi devre dışı bırakın (özellikle kaynağınızın aranabilir olmasını istiyorsanız obj dizinleri)

Bu bir web uygulamasıysa, senaryoya bağlı olarak toplu derlemeyi doğru olarak ayarlamak yardımcı olabilir.

<compilation defaultLanguage="c#" debug="true" batch="true" >  

Burada bir genel bakış bulabilirsiniz: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Ayrıca döngüsel proje referanslarını da kontrol etmek isteyebilirsiniz. Bir zamanlar benim için bir sorundu.

Yani:

Proje A referansları Proje B

Proje B referansları Proje C

Proje C referansları Proje A

Xoreax IB'ye göre daha ucuz bir alternatif, benim uber dosyası derlemeleri dediğim şeyin kullanılmasıdır. Temelde bir .cpp dosyasıdır.

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Ardından, tek tek modüller yerine uber birimleri derlersiniz. 10-15 dakikadan 1-2 dakikaya kadar derleme süreleri gördük. Uber dosyası başına kaç tane #includes'in mantıklı olduğunu deneyimlemeniz gerekebilir. Projelere göre değişir. vb. Belki 10, belki 20 dosya eklersiniz.

Bir bedel ödüyorsunuz, bu yüzden dikkatli olun:

1. Bir dosyaya sağ tıklayıp "derle ..." diyemezsiniz çünkü tek tek cpp dosyalarını derlemeden hariç tutmanız ve yalnızca uber cpp dosyalarını dahil etmeniz gerekir.
2. Statik global değişken çakışmalarına karşı dikkatli olmalısınız.
3. Yeni modüller eklediğinizde, uber dosyalarını güncel tutmanız gerekir

Bu biraz acı, ancak yeni modüller açısından büyük ölçüde durağan olan bir proje için, ilk acı buna değebilir. Bu yöntemin bazı durumlarda IB'yi geçtiğini gördüm.

Bu bir C ++ projesiyse, önceden derlenmiş başlıklar kullanmalısınız. Bu, derleme sürelerinde büyük bir fark yaratır. Cl.exe'nin gerçekten ne yaptığından emin değilsiniz (önceden derlenmiş başlıkları kullanmadan), sonunda doğru yere gitmeden önce tüm yanlış yerlerde çok sayıda STL başlığı arıyor gibi görünüyor . Bu, derlenen her bir .cpp dosyasına tam saniye ekler. Bunun bir cl.exe hatası mı yoksa VS2008'de bir çeşit STL sorunu mu olduğundan emin değilim.

Üzerine inşa ettiğiniz makineye baktığınızda, optimum şekilde yapılandırılmış mı?

Biz sadece aşağı bizim büyük C ++ kurumsal ölçekli ürün için bizim yapı zaman var 19 saat için 16 dakika sağ SATA filtre sürücüsü yüklendiği sağlayarak.

İnce.

Visual Studio 2005'te belgelenmemiş / MP anahtarı var, bkz. Http://lahsiv.net/blog/?p=40 , proje bazında değil dosya bazında paralel derlemeyi etkinleştirir. Bu, son projenin derlenmesini hızlandırabilir veya bir proje derlerseniz.

Bir CPU seçerken: L1 önbellek boyutunun derleme süresi üzerinde büyük bir etkisi var gibi görünüyor. Ayrıca, 4 yavaş çekirdeğe göre 2 hızlı çekirdeğe sahip olmak genellikle daha iyidir. Visual Studio, ekstra çekirdekleri çok etkili bir şekilde kullanmaz. (Bunu C ++ derleyicisiyle olan deneyimime dayandırıyorum, ancak muhtemelen C # biri için de geçerlidir.)

Ayrıca artık VS2008 ile ilgili bir sorun olduğuna ikna oldum. Anti-virüs özelliği kapalı, 3G Ram'li çift çekirdekli bir Intel dizüstü bilgisayarda çalıştırıyorum. Çözümü derlemek genellikle oldukça zahmetlidir, ancak sonraki bir yeniden derlemede hata ayıklama yaptıysam, genellikle bir taramaya yavaşlar. Sürekli ana disk ışığından, bir disk G / Ç darboğazı olduğu açıktır (bunu siz de duyabilirsiniz). Derlemeyi iptal edersem ve VS'yi kapatırsam disk etkinliği durur. VS'yi yeniden başlatın, çözümü yeniden yükleyin ve ardından yeniden oluşturun; çok daha hızlıdır. Bir dahaki sefere birim

Düşüncelerim, bunun bir bellek sayfalama sorunu olduğu - VS'nin hafızası bitiyor ve O / S, yer açmaya çalışmak için sayfa değiştirmeye başlıyor, ancak VS, sayfa değiştirmenin sağlayabileceğinden daha fazlasını talep ediyor, bu yüzden bir taramaya yavaşlıyor. Başka bir açıklama düşünemiyorum.

VS kesinlikle bir RAD aracı değil, değil mi?

Şirketiniz PKI / Şifreleme çözümü için herhangi bir şans eseri Entrust kullanıyor mu? Görünüşe göre, C # ile oluşturulmuş oldukça büyük bir web sitesi için berbat bir derleme performansı elde ediyorduk ve Tümünü Yeniden Oluştur'da 7 dakikadan fazla zaman harcıyorduk.

Makinem 16gb ram ve 512GB SSD'ye sahip bir i7-3770, bu yüzden performans o kadar da kötü olmamalıydı. Aynı kod tabanını oluşturan eski bir ikincil makinede derleme sürelerimin delicesine daha hızlı olduğunu fark ettim. Bu yüzden her iki makinede de ProcMon'u çalıştırdım, yapıların profilini çıkardım ve sonuçları karşılaştırdım.

Bakın, yavaş işleyen makinenin tek bir farkı vardı - yığın izlemesindeki Entrust.dll'ye bir başvuru. Bu yeni edindiğim bilgiyi kullanarak, StackOverflow'u aramaya devam ettim ve şunu buldum: MSBUILD (VS2010) bazı makinelerde çok yavaş . Kabul edilen cevaba göre sorun, Entrust işleyicisinin yerel Microsoft işleyicisi yerine .NET sertifika kontrollerini işliyor olması gerçeğinde yatmaktadır. Tt'nin ayrıca Entrust v10'un Entrust 9'da yaygın olan bu sorunu çözmesi önerilmektedir.

Şu anda onu kaldırdım ve yapım sürelerim 24 saniyeye düştü . Şu anda inşa etmekte olduğunuz projelerin sayısı ile YYMV, sorduğunuz ölçeklendirme sorununu doğrudan ele alamayabilir. Ben bir düzeltme sağlayabilir eğer bu yanıtı bir düzenleme yayınlayacağız olmadan bir kaldırma yazılımı başvurmadan.

VS2008 ile ilgili bir sorun olduğundan emin. Çünkü yaptığım tek şey, VS2005 ile oluşturduğum projemi yükseltmek için VS2008'i kurmak. Çözümümde sadece 2 projem var. Büyük değil. VS2005 ile Derleme: VS2008 ile 30 saniye Derleme: 5 dakika

Şimdiye kadar yardımcı olan güzel öneriler (aşağıda başka güzel öneriler olmadığını söylemiyoruz, sorun yaşıyorsanız, o zaman okumanızı tavsiye ederim, sadece bize yardımcı olan şeyi)

• Yeni 3GHz dizüstü bilgisayar - kayıp kullanımın gücü, yönetime sızlanırken harikalar yaratıyor
• Derleme sırasında Anti Virüsü devre dışı bırakın
• Derleme sırasında VSS'den (aslında ağ) 'bağlantının kesilmesi' - VS-VSS entegrasyonunu tamamen kaldırmamızı ve VSS kullanıcı arayüzünü kullanmaya devam etmemizi sağlayabilirim

Yine de bir derlemede rip-snorting değil, ama her parçası yardımcı oluyor.

Ayrıca yeni çözümlerde yeni uygulama alanları oluşturma, gerektiğinde en son dll'leri içe aktararak, onlardan memnun olduğumuzda bunları daha büyük çözüme entegre etme pratiğini test ediyoruz.

Bunları, sadece üzerinde çalışmamız gereken alanları kapsayan geçici çözümler oluşturarak ve kodu yeniden entegre ettikten sonra bunları atarak mevcut koda da aynısını yapabiliriz. Geliştirme sırasında Rip Van Winkle gibi deneyimler yaşamamakla kazandığımız zamana karşı bu kodu yeniden entegre etmek için gereken zamanı tartmamız gerekiyor.

Orion, jenerik ilaçların da bir oyun oynayabileceğinden bahsetti. Testlerime göre minimum performans vuruşu var gibi görünüyor, ancak emin olmak için yeterince yüksek değil - disk etkinliği nedeniyle derleme süreleri tutarsız olabilir. Zaman sınırlamaları nedeniyle, testlerim canlı sistemde göründüğü kadar çok Jenerik veya kod içermiyordu, bu yüzden birikebilir. Sadece derleme zamanı performansı için kullanılması gereken yerde jenerik kullanmaktan kaçınmam