Czas kompilacji jest bardzo długi, co może zająć ponad 20 minut na maszynach dwurdzeniowych 2GHz i 2G RAM.

Wiele z tego wynika z rozmiaru naszego rozwiązania, które rozrosło się do ponad 70 projektów, a także VSS, który sam w sobie jest wąskim gardłem, gdy masz dużo plików. (zamiana VSS nie jest niestety opcją, więc nie chcę, aby to schodziło w bash VSS)

Szukamy możliwości łączenia projektów. Rozglądamy się również za wieloma rozwiązaniami, które pozwolą uzyskać większą separację problemów i szybsze czasy kompilacji dla każdego elementu aplikacji. Widzę, że stanie się to piekłem DLL, gdy będziemy starać się utrzymać synchronizację.

Interesuje mnie, jak inne zespoły poradziły sobie z tym problemem skalowania, co robisz, gdy baza kodu osiąga masę krytyczną, którą marnujesz pół dnia, obserwując, jak pasek stanu dostarcza kompilowane komunikaty.

UPDATE Zapomniałem wspomnieć, że jest to rozwiązanie C #. Dzięki za wszystkie sugestie C ++, ale minęło kilka lat, odkąd musiałem martwić się o nagłówki.

EDYTOWAĆ:

Ładne sugestie, które do tej pory pomogły (nie mówiąc, że poniżej nie ma innych fajnych sugestii, tylko to, co pomogło)

• Nowy laptop 3GHz - moc utraconego wykorzystania działa cuda, gdy zwracasz się do zarządzania
• Wyłącz program antywirusowy podczas kompilacji
• „Odłączanie” od VSS (właściwie sieci) podczas kompilacji - mogę całkowicie usunąć integrację VS-VSS i trzymać się interfejsu VSS UI

Nadal nie przepycham kompilacji, ale wszystko pomaga.

Orion wspomniał w komentarzu, że leki generyczne również mogą mieć znaczenie. Z moich testów wynika, że ​​wydajność jest minimalna, ale niewystarczająco wysoka, aby być pewnym - czasy kompilacji mogą być niespójne ze względu na aktywność dysku. Ze względu na ograniczenia czasowe moje testy nie obejmowały tylu typów generycznych ani tylu kodu, ile pojawiłoby się w systemie na żywo, więc może się to kumulować. Nie unikałbym używania typów generycznych tam, gdzie mają być używane, tylko dla wydajności czasu kompilacji

OBEJŚCIE

Testujemy praktykę budowania nowych obszarów aplikacji w nowych rozwiązaniach, importując w razie potrzeby najnowsze biblioteki dll i integrując je z większym rozwiązaniem, gdy jesteśmy z nich zadowoleni.

Możemy również zrobić to samo z istniejącym kodem, tworząc tymczasowe rozwiązania, które po prostu hermetyzują obszary, nad którymi musimy popracować, i wyrzucając je po ponownej integracji kodu. Musimy zważyć czas potrzebny na ponowną integrację tego kodu z czasem, który zyskamy, nie mając doświadczeń Rip Van Winkle jak z szybką rekompilacją podczas programowania.

Zespół Chromium.org wymienił kilka opcji przyspieszenia kompilacji (w tym miejscu mniej więcej w połowie strony):

W malejącej kolejności przyspieszania:

• Zainstaluj poprawkę Microsoft 935225 .
• Zainstaluj poprawkę Microsoft 947315 .
• Użyj prawdziwego procesora wielordzeniowego (tj. Intel Core Duo 2; nie Pentium 4 HT).
• Użyj 3 równoległych kompilacji. W programie Visual Studio 2005 znajdziesz opcję w Narzędzia> Opcje ...> Projekty i rozwiązania> Kompiluj i uruchamiaj> maksymalna liczba równoległych kompilacji projektów .
• Wyłącz oprogramowanie antywirusowe dla plików .ilk, .pdb, .cc, .h i sprawdzaj wirusy tylko podczas modyfikacji . Wyłącz skanowanie katalogu, w którym znajdują się źródła. Nie rób nic głupiego.
• Przechowuj i buduj kod Chromium na drugim dysku twardym. Naprawdę nie przyspieszy to kompilacji, ale przynajmniej Twój komputer będzie reagował podczas synchronizacji gclient lub kompilacji.
• Regularnie defragmentuj dysk twardy.
• Wyłącz pamięć wirtualną.

Mamy blisko 100 projektów w jednym rozwiązaniu, a czas budowy dewelopera to zaledwie kilka sekund :)

Rozwoju lokalnego buduje stworzyliśmy Visual Studio Addin, że zmiany Project referencesdo DLL referencesi rozładowuje niechcianych projektów (oraz opcjonalnie przełączyć je oczywiście).

• Zbuduj całe nasze rozwiązanie raz
• Zwolnij projekty, nad którymi obecnie nie pracujemy, i zmień wszystkie odwołania do projektów na odwołania do bibliotek DLL.
• Przed zaewidencjonowaniem zmień wszystkie odwołania z powrotem z biblioteki DLL na odwołania do projektu.

Nasze kompilacje zajmują teraz tylko kilka sekund, gdy pracujemy tylko nad kilkoma projektami naraz. Możemy również nadal debugować dodatkowe projekty, ponieważ łączy się z bibliotekami DLL debugowania. Narzędzie zwykle wprowadza dużą liczbę zmian w 10–30 sekund, ale nie musisz robić tego tak często.

Aktualizacja maj 2015

Umowa, którą zawarłem (w komentarzach poniżej), polegała na tym, że wypuściłbym wtyczkę do Open Source, jeśli spotka się z wystarczającym zainteresowaniem. 4 lata później ma już tylko 44 głosy (a Visual Studio ma teraz dwie kolejne wersje), więc jest to obecnie projekt o niskim priorytecie.

Miałem podobny problem z rozwiązaniem z 21 projektami i 1/2 miliona LOC. Największą różnicą było uzyskanie szybszych dysków twardych. Z monitora wydajności „Śr. Disk Queue ”znacznie podskoczyło na laptopie, wskazując, że dysk twardy był szyjką butelki.

Oto kilka danych dotyczących całkowitego czasu odbudowy ...

1) Laptop, Core 2 Duo 2GHz, dysk 5400 RPM (brak pewności co do pamięci podręcznej. Był to standardowy Dell Inspiron).

Czas odbudowy = 112 sekund.

2) Komputer stacjonarny (wersja standardowa), Core 2 Duo 2,3 GHz, pojedynczy dysk 7200 obr./min, 8 MB pamięci podręcznej.

Czas odbudowy = 72 sekundy.

3) Desktop Core 2 Duo 3Ghz, pojedynczy WD Raptor 10000 RPM

Czas odbudowy = 39 sekund.

Dysk o prędkości 10 000 obr./min nie może być zaniżony. Kompilacje, które były znacznie szybsze oraz wszystko inne, takie jak wyświetlanie dokumentacji, korzystanie z eksploratora plików było zauważalne szybciej. Był to duży wzrost produktywności dzięki przyspieszeniu cyklu uruchamiania kodu.

Biorąc pod uwagę to, ile firmy wydają na pensje programistów, to szalone, ile mogą zmarnować, kupując wyposażenie ich w te same komputery, których używa recepcjonistka.

W przypadku kompilacji C # .NET można użyć .NET Demon . Jest to produkt, który przejmuje proces kompilacji programu Visual Studio, aby go przyspieszyć.

Odbywa się to poprzez analizę wprowadzonych zmian i buduje tylko projekt, który faktycznie zmieniłeś, a także inne projekty, które faktycznie opierały się na wprowadzonych zmianach. Oznacza to, że jeśli zmienisz tylko kod wewnętrzny, wystarczy skompilować tylko jeden projekt.

Wyłącz program antywirusowy. Dodaje wieki do czasu kompilacji.

Użyj kompilacji rozproszonej. Xoreax IncrediBuild może skrócić czas kompilacji do kilku minut.

Użyłem go w ogromnym rozwiązaniu C \ C ++, którego kompilacja zajmuje zwykle 5-6 godzin. IncrediBuild pomogło skrócić ten czas do 15 minut.

Instrukcje dotyczące skrócenia czasu kompilacji programu Visual Studio do kilku sekund

Program Visual Studio nie jest niestety wystarczająco inteligentny, aby odróżnić zmiany interfejsu zestawu od niekonsekwentnych zmian treści kodu. Ten fakt, w połączeniu z dużymi, przeplatanymi rozwiązaniami, może czasami stworzyć idealną burzę niechcianych „pełnych kompilacji” prawie za każdym razem, gdy zmieniasz pojedynczą linię kodu.

Strategią pozwalającą przezwyciężyć ten problem jest wyłączenie automatycznego budowania drzewa odwołań. Aby to zrobić, użyj `` Configuration Manager '' (Build / Configuration Manager ..., a następnie w menu rozwijanym Active solution configuration, wybierz `` New ''), aby utworzyć nową konfigurację kompilacji o nazwie `` ManualCompile '', która kopiuje z konfiguracji debugowania, ale zrób nie zaznaczaj pola wyboru „Utwórz nowe konfiguracje projektu”. W tej nowej konfiguracji kompilacji odznacz każdy projekt, aby żaden z nich nie budował się automatycznie. Zapisz tę konfigurację, naciskając „Zamknij”. Ta nowa konfiguracja kompilacji zostanie dodana do pliku rozwiązania.

Możesz przełączać się z jednej konfiguracji kompilacji na inną za pomocą menu rozwijanego konfiguracji kompilacji u góry ekranu IDE (tego, które zwykle pokazuje „Debuguj” lub „Wydanie”). W rzeczywistości ta nowa konfiguracja kompilacji ManualCompile sprawi, że opcje menu Build dla: „Build Solution” lub „Rebuild Solution” będą bezużyteczne. Dlatego w trybie ManualCompile należy ręcznie skompilować każdy projekt, który modyfikujesz, co można zrobić, klikając prawym przyciskiem myszy każdy projekt, którego dotyczy problem, w Eksploratorze rozwiązań, a następnie wybierając opcję „Kompiluj” lub „Przebuduj”. Powinieneś zobaczyć, że całkowity czas kompilacji będzie teraz wynosił zaledwie kilka sekund.

Aby ta strategia działała, konieczne jest, aby numer VersionNumber znajdujący się w plikach AssemblyInfo i GlobalAssemblyInfo pozostał statyczny na komputerze dewelopera (oczywiście nie podczas kompilacji wydania) i nie podpisujesz bibliotek DLL.

Potencjalne ryzyko korzystania z tej strategii ManualCompile polega na tym, że programista może zapomnieć o skompilowaniu wymaganych projektów, a po uruchomieniu debugera uzyskuje nieoczekiwane wyniki (nie można dołączyć debugera, nie znaleziono plików itp.). Aby tego uniknąć, prawdopodobnie najlepiej jest użyć konfiguracji kompilacji „Debuguj”, aby skompilować większy wysiłek związany z kodowaniem, i używać konfiguracji kompilacji ManualCompile tylko podczas testów jednostkowych lub do wprowadzania szybkich zmian o ograniczonym zakresie.

Jeśli to jest C lub C ++ i nie używasz prekompilowanych nagłówków, powinieneś.

W naszym głównym rozwiązaniu mieliśmy ponad 80 projektów, których zbudowanie zajęło około 4 do 6 minut w zależności od rodzaju maszyny, na której pracował programista. Uznaliśmy, że jest to o wiele za długie: w przypadku każdego testu naprawdę zjada Twoje pełne etaty.

Jak więc uzyskać szybsze czasy kompilacji? Jak wydaje się już wiesz, jest to liczba projektów, które naprawdę szkodzą czasowi budowy. Oczywiście nie chcieliśmy pozbywać się wszystkich naszych projektów i po prostu wrzucić wszystkie pliki źródłowe do jednego. Ale mieliśmy kilka projektów, które mimo wszystko mogliśmy łączyć: Ponieważ każdy „projekt repozytorium” w rozwiązaniu miał swój własny, najbardziej nieprzejrzysty projekt, po prostu połączyliśmy wszystkie najbardziej nieprzewidziane projekty w jeden globalny projekt. Zmniejszyło to liczbę projektów z około 12 projektami i w jakiś sposób zaoszczędziło 40% czasu na zbudowanie całego rozwiązania.

Myślimy jednak o innym rozwiązaniu.

Czy próbowałeś również skonfigurować nowe (drugie) rozwiązanie z nowym projektem? To drugie rozwiązanie powinno po prostu obejmować wszystkie pliki przy użyciu folderów rozwiązań. Ponieważ możesz być zaskoczony, widząc czas kompilacji tego nowego rozwiązania z tylko jednym projektem.

Jednak praca z dwoma różnymi rozwiązaniami wymaga starannego rozważenia. Deweloperzy mogą być skłonni faktycznie -pracować- w drugim rozwiązaniu i całkowicie zaniedbać pierwsze. Ponieważ pierwsze rozwiązanie z ponad 70 projektami będzie rozwiązaniem, które zadba o twoją hierarchię obiektów, powinno to być rozwiązanie, w którym twój buildserver powinien uruchamiać wszystkie twoje unittesty. Zatem serwer ciągłej integracji musi być pierwszym projektem / rozwiązaniem. Musisz zachować swoją hierarchię obiektów, prawda.

Drugim rozwiązaniem z tylko jednym projektem (który będzie budował się znacznie szybciej) będzie projekt, w którym testowanie i debugowanie będą wykonywane przez wszystkich programistów. Musisz się jednak nimi zająć, patrząc na serwer kompilacji! Jeśli coś się zepsuje, MUSI to naprawić.

Upewnij się, że odwołania są odwołaniami do projektu, a nie bezpośrednio do bibliotek DLL w katalogach wyjściowych biblioteki.

Ustaw je tak, aby nie kopiowały lokalnie, chyba że jest to absolutnie konieczne (projekt główny EXE).

Pierwotnie opublikowałem tę odpowiedź tutaj: /programming/8440/visual-studio-optimizations#8473 Na tej stronie można znaleźć wiele innych pomocnych wskazówek.

Jeśli używasz programu Visual Studio 2008, możesz skompilować przy użyciu flagi / MP, aby równolegle skompilować pojedynczy projekt. Czytałem, że jest to również nieudokumentowana funkcja w programie Visual Studio 2005, ale nigdy nie próbowałem sam.

Możesz budować wiele projektów równolegle, używając flagi / M, ale zwykle jest to już ustawione na liczbę dostępnych rdzeni na komputerze, chociaż wydaje mi się, że dotyczy to tylko VC ++.

Zauważyłem, że to pytanie jest stare, ale temat jest nadal interesujący. Ostatnio ugryzł mnie ten sam problem, a dwie rzeczy, które najbardziej poprawiły wydajność kompilacji, to (1) użycie dedykowanego (i szybkiego) dysku do kompilacji oraz (2) użycie tego samego folderu wyjściowego dla wszystkich projektów i ustawienie CopyLocal na False w projekcie Bibliografia.

Dodatkowe zasoby:

• /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/

Niektóre narzędzia analityczne:

tools-> options-> ustawienia projektu VC ++ -> Build Timing = Yes powie Ci czas kompilacji dla każdego vcproj.

Dodaj /Btprzełącznik do wiersza poleceń kompilatora, aby zobaczyć, ile zajął każdy plik CPP

Służy /showIncludesdo przechwytywania zagnieżdżonych dołączeń (plików nagłówkowych, które zawierają inne pliki nagłówkowe) i sprawdzania, które pliki mogą zaoszczędzić dużo operacji we / wy przy użyciu deklaracji przekazywania.

Pomoże to zoptymalizować wydajność kompilatora poprzez wyeliminowanie zależności i ograniczeń wydajności.

Zanim wydasz pieniądze na inwestycje w szybsze dyski twarde, spróbuj zbudować swój projekt w całości na dysku RAM (zakładając, że masz wolną pamięć RAM). W sieci można znaleźć różne darmowe sterowniki dysku RAM. Nie znajdziesz żadnego dysku fizycznego, w tym dysków SSD, które byłyby szybsze niż dysk RAM.

W moim przypadku projekt, którego budowa zajęła 5 minut na 6-rdzeniowym i7 na dysku SATA 7200 obr./min z Incredibuild, został skrócony tylko o około 15 sekund dzięki zastosowaniu dysku RAM. Biorąc pod uwagę konieczność ponownego kopiowania do stałego magazynu i możliwość utraty pracy, 15 sekund nie jest wystarczającą zachętą do korzystania z dysku RAM i prawdopodobnie nie jest dużą zachętą do wydania kilkuset dolarów na dysk o wysokiej prędkości obrotowej lub SSD.

Niewielki wzrost może wskazywać, że kompilacja była związana z procesorem lub że buforowanie plików systemu Windows było raczej skuteczne, ale ponieważ oba testy zostały wykonane w stanie, w którym pliki nie były buforowane, mocno skłaniam się ku kompilacjom związanym z procesorem.

W zależności od faktycznego kodu, który kompilujesz, przebieg może się różnić - więc nie wahaj się przetestować.

Jak duży jest katalog kompilacji po wykonaniu pełnej kompilacji? Jeśli pozostaniesz przy domyślnej konfiguracji, każdy zestaw, który zbudujesz, skopiuje wszystkie biblioteki DLL swoich zależności i zależności itp. Do swojego katalogu bin. W mojej poprzedniej pracy, podczas pracy z rozwiązaniem obejmującym ~ 40 projektów, moi koledzy odkryli, że zdecydowanie najdroższą częścią procesu kompilacji było wielokrotne kopiowanie tych zestawów, a jedna kompilacja mogła generować gigabajty kopii tych samych bibliotek DLL w kółko jeszcze raz.

Oto kilka przydatnych rad od Patricka Smacchii, autora NDepend, na temat tego, co jego zdaniem powinno, a co nie powinno być oddzielnymi zgromadzeniami:

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

Istnieją zasadniczo dwa sposoby obejścia tego problemu i oba mają wady. Jednym z nich jest zmniejszenie liczby złożeń, co oczywiście wymaga dużo pracy. Innym jest restrukturyzacja katalogów kompilacji, tak aby wszystkie foldery bin zostały skonsolidowane, a projekty nie kopiowały bibliotek DLL ich zależności - nie muszą tego robić, ponieważ wszystkie znajdują się już w tym samym katalogu. To radykalnie zmniejsza liczbę plików tworzonych i kopiowanych podczas kompilacji, ale może to być trudne do skonfigurowania i może powodować pewne trudności z wyciągnięciem tylko bibliotek DLL wymaganych przez określony plik wykonywalny do pakowania.

Być może weźmiesz jakieś wspólne funkcje i utwórz biblioteki, w ten sposób te same źródła nie będą kompilowane w kółko dla wielu projektów.

Jeśli obawiasz się pomieszania różnych wersji bibliotek DLL, użyj bibliotek statycznych.

Wyłącz integrację VSS. Możesz nie mieć wyboru, aby go używać, ale nazwy bibliotek DLL są przez cały czas „przypadkowo” zmieniane ...

I zdecydowanie sprawdź swoje wstępnie skompilowane ustawienia nagłówka. Przewodnik Bruce'a Dawsona jest nieco stary, ale nadal bardzo dobry - sprawdź: http://www.cygnus-software.com/papers/precompiledheaders.html

Mam projekt, który ma 120 lub więcej plików exe, bibliotek i bibliotek dll, a jego zbudowanie zajmuje dużo czasu. Używam drzewa plików wsadowych, które wywołują pliki make z jednego głównego pliku wsadowego. W przeszłości miałem problemy z dziwnymi rzeczami związanymi z przyrostowymi (a może był to temperament) nagłówkami, więc teraz ich unikam. Rzadko wykonuję pełną kompilację i zwykle zostawiam ją na koniec dnia, gdy idę na spacer na godzinę (więc mogę się tylko domyślać, że zajmuje to około pół godziny). Rozumiem więc, dlaczego jest to niewykonalne podczas pracy i testowania.

Do pracy i testowania mam inny zestaw plików wsadowych dla każdej aplikacji (lub modułu lub biblioteki), które również mają wszystkie ustawienia debugowania - ale nadal wywołują te same pliki make. Mogę od czasu do czasu włączać lub wyłączać DEBUG, a także decydować o kompilacjach lub markach lub o tym, czy chcę również budować biblioteki, od których może zależeć moduł, i tak dalej.

Plik wsadowy kopiuje również ukończony wynik do (lub kilku) folderów testowych. W zależności od ustawień trwa to od kilku sekund do minuty (w przeciwieństwie do powiedzmy pół godziny).

Użyłem innego IDE (Zeus), ponieważ lubię mieć kontrolę nad takimi rzeczami, jak pliki .rc, i właściwie wolę kompilować z wiersza poleceń, mimo że używam zgodności z MS.

Z przyjemnością zamieszczam przykład tego pliku wsadowego, jeśli ktoś jest zainteresowany.

Wyłącz indeksowanie systemu plików w katalogach źródłowych (w szczególności katalogach obj, jeśli chcesz, aby można było przeszukiwać źródła)

Jeśli jest to aplikacja internetowa, ustawienie kompilacji wsadowej na true może pomóc w zależności od scenariusza.

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

Przegląd można znaleźć tutaj: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Możesz również sprawdzić, czy istnieją cykliczne odniesienia do projektów. Kiedyś to był dla mnie problem.

To jest:

Projekt A odwołuje się do Projektu B

Projekt B odwołuje się do Projektu C

Projekt C odwołuje się do Projektu A

Jedną z tańszych alternatyw dla Xoreax IB jest użycie tego, co nazywam kompilacjami plików uber. Jest to po prostu plik .cpp, który ma

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

Następnie kompilujesz jednostki nadrzędne zamiast poszczególnych modułów. Widzieliśmy czasy kompilacji od 10-15 minut do 1-2 minut. Być może będziesz musiał poeksperymentować z tym, ile #include na plik uber ma sens. Zależy od projektów. itd. Może załączysz 10 plików, może 20.

Płacisz, więc uważaj:

1. Nie możesz kliknąć pliku prawym przyciskiem myszy i powiedzieć „kompiluj ...”, ponieważ musisz wykluczyć poszczególne pliki cpp z kompilacji i uwzględnić tylko pliki cpp uber
2. Musisz uważać na statyczne globalne konflikty zmiennych.
3. Dodając nowe moduły, musisz aktualizować pliki Uber

To trochę uciążliwe, ale w przypadku projektu, który jest w dużej mierze statyczny pod względem nowych modułów, początkowy ból może być tego wart. Widziałem, jak ta metoda w niektórych przypadkach pokonała IB.

Jeśli jest to projekt w C ++, powinieneś używać prekompilowanych nagłówków. To powoduje ogromną różnicę w czasie kompilacji. Nie jestem pewien, co naprawdę robi cl.exe (bez używania prekompilowanych nagłówków), wydaje się, że szuka wielu nagłówków STL we wszystkich niewłaściwych miejscach, zanim ostatecznie przejdzie do właściwej lokalizacji. To dodaje całe sekundy do każdego kompilowanego pliku .cpp. Nie jestem pewien, czy jest to błąd programu cl.exe, czy jakiś problem STL w VS2008.

Patrząc na maszynę, na której budujesz, czy jest ona optymalnie skonfigurowana?

Dopiero co skrócił nasz czas kompilacji naszego największego produktu C ++ na skalę korporacyjną z 19 godzin do 16 minut dzięki zainstalowaniu odpowiedniego sterownika filtru SATA.

Subtelny.

W Visual Studio 2005 jest nieudokumentowany przełącznik / MP, zobacz http://lahsiv.net/blog/?p=40 , który umożliwiłby równoległą kompilację na podstawie pliku, a nie projektu. Może to przyspieszyć kompilację ostatniego projektu lub, jeśli kompilujesz jeden projekt.

Przy wyborze procesora: rozmiar pamięci podręcznej L1 wydaje się mieć ogromny wpływ na czas kompilacji. Zwykle lepiej jest mieć 2 szybkie rdzenie niż 4 wolne. Program Visual Studio nie wykorzystuje bardzo efektywnie dodatkowych rdzeni. (Opieram się na moich doświadczeniach z kompilatorem C ++, ale prawdopodobnie dotyczy to również wersji C #).

Jestem teraz przekonany, że wystąpił problem z VS2008. Używam go na dwurdzeniowym laptopie Intela z 3G Ram, z wyłączonym antywirusem. Kompilowanie rozwiązania jest często dość sprawne, ale jeśli debugowałem, kolejna rekompilacja często spowalnia do indeksowania. Z ciągłego światła głównego dysku jasno wynika, że ​​występuje wąskie gardło we / wy dysku (też można to usłyszeć). Jeśli anuluję kompilację i zamknę VS, aktywność dysku zostanie zatrzymana. Zrestartuj VS, przeładuj rozwiązanie, a następnie odbuduj i jest znacznie szybsze. Unitl następnym razem

Myślę, że jest to problem ze stronicowaniem pamięci - VS po prostu zabraknie pamięci, a system operacyjny rozpoczyna zamianę stron, aby spróbować zwolnić miejsce, ale VS wymaga więcej niż zamiana stron może dostarczyć, więc spowalnia do indeksowania. Nie przychodzi mi do głowy żadne inne wyjaśnienie.

VS zdecydowanie nie jest narzędziem RAD, prawda?

Czy zdarza się, że Twoja firma korzysta z Entrust w ramach rozwiązania PKI / Encryption? Okazuje się, że mieliśmy fatalną wydajność kompilacji dla dość dużej witryny internetowej zbudowanej w C #, która zajęła 7+ minut na Rebuild-All.

Mój komputer to i7-3770 z 16 GB pamięci RAM i 512 GB SSD, więc wydajność nie powinna być tak zła. Zauważyłem, że czas kompilacji był niesamowicie krótszy na starszej maszynie pomocniczej, która budowała ten sam kod. Więc uruchomiłem ProcMon na obu maszynach, sprofilowałem kompilacje i porównałem wyniki.

I oto, wolno działająca maszyna miała jedną różnicę - odwołanie do Entrust.dll w stacktrace. Korzystając z tych nowo uzyskanych informacji, kontynuowałem przeszukiwanie StackOverflow i znalazłem to: MSBUILD (VS2010) bardzo wolno na niektórych komputerach . Zgodnie z przyjętą odpowiedzią, problem polega na tym, że procedura obsługi Entrust przetwarzała sprawdzanie certyfikatów .NET zamiast natywnej procedury obsługi Microsoft. Sugeruje się również, że Entrust v10 rozwiązuje ten problem, który jest powszechny w Entrust 9.

Obecnie mam go odinstalowany, a czas kompilacji spadł do 24 sekund . YYMV z liczbą projektów, które obecnie budujesz i może nie uwzględniać bezpośrednio problemu skalowania, o który pytałeś. Opublikuję zmianę w tej odpowiedzi, jeśli mogę zapewnić poprawkę bez uciekania się do dezinstalacji oprogramowania.

Na pewno jest problem z VS2008. Ponieważ jedyne, co zrobiłem, to zainstalowanie VS2008 do aktualizacji mojego projektu, który został utworzony za pomocą VS2005. Mam tylko 2 projekty w moim rozwiązaniu. Nie jest duży. Kompilacja z VS2005: 30 sekund Kompilacja z VS2008: 5 minut

Ładne sugestie, które do tej pory pomogły (nie mówiąc, że nie ma innych fajnych sugestii poniżej, jeśli masz problemy, polecam przeczytanie wtedy, tylko co nam pomogło)

• Nowy laptop 3GHz - moc utraconego wykorzystania działa cuda, gdy zwracasz się do zarządzania
• Wyłącz program antywirusowy podczas kompilacji
• „Odłączanie” od VSS (właściwie sieci) podczas kompilacji - mogę całkowicie usunąć integrację VS-VSS i trzymać się interfejsu VSS UI

Nadal nie przepycham kompilacji, ale wszystko pomaga.

Testujemy również praktykę budowania nowych obszarów aplikacji w nowych rozwiązaniach, importując w razie potrzeby najnowsze biblioteki dll i integrując je z większym rozwiązaniem, gdy jesteśmy z nich zadowoleni.

Możemy również zrobić to samo z istniejącym kodem, tworząc tymczasowe rozwiązania, które po prostu hermetyzują obszary, nad którymi musimy popracować, i wyrzucając je po ponownej integracji kodu. Musimy zważyć czas potrzebny na ponowną integrację tego kodu z czasem, który zyskamy, nie mając doświadczeń Rip Van Winkle jak z szybką rekompilacją podczas programowania.

Orion wspomniał w komentarzu, że leki generyczne również mogą mieć znaczenie. Z moich testów wynika, że ​​wydajność jest minimalna, ale niewystarczająco wysoka, aby być pewnym - czasy kompilacji mogą być niespójne ze względu na aktywność dysku. Ze względu na ograniczenia czasowe moje testy nie obejmowały tylu typów generycznych ani tylu kodu, ile pojawiłoby się w systemie na żywo, więc może się to kumulować. Nie unikałbym używania typów generycznych tam, gdzie mają być używane, tylko dla wydajności czasu kompilacji