Bardzo wolne czasy kompilacji w Visual Studio 2005

Mamy blisko 100 projektów w jednym rozwiązaniu, a czas tworzenia dev to zaledwie kilka sekund:)]}

Dla kompilacji local development stworzyliśmy dodatek Visual Studio, który zmienia Project references na DLL references i rozładowuje niechciane projekty (i oczywiście możliwość ich zmiany z powrotem).

• Zbuduj nasze całe rozwiązanie raz
• rozładuj projekty, nad którymi obecnie nie pracujemy i zmień wszystkie odniesienia do projektów NA odniesienia DLL.
• przed odprawą zmień wszystkie referencje powrót z DLL do referencji projektu.

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

Aktualizacja Maj 2015

Umowa, którą zawarłem (w komentarzach poniżej), polegała na tym, że wydam wtyczkę do Open Source jeśli wystarczy odsetki. 4 lata później ma 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 coraz szybsze dyski twarde. Z Monitora wydajności ' Avg. Kolejka dysków " wskoczyłaby znacznie w górę na laptopie wskazując, że dysk twardy był szyjką butelki.

Oto kilka danych na temat całkowitych czasów odbudowy...

1) Laptop, Core 2 Duo 2GHz, 5400 RPM Drive (nie jestem pewien cache. Był standard Dell inspiron).

Czas odbudowy = 112 sekund.

2) pulpit (standard issue), Core 2 Duo 2.3 Ghz, pojedynczy dysk 7200RPM 8MB Cache.

Czas odbudowy = 72 sekundy.

3) Desktop Core 2 Duo 3GHz, single 10000 RPM WD Raptor

Czas odbudowy = 39 sekund.

Napęd 10 000 obr. / min nie może być zaniżony. Buduje się tam, gdzie znacznie szybciej plus Wszystko inne, takie jak wyświetlanie dokumentacji, korzystanie z Eksploratora plików było zauważalne szybciej. To był duży wzrost wydajności poprzez przyspieszenie cyklu kod-Budowa-uruchomienie.

Biorąc pod uwagę, co firmy wydają na pensje deweloperów to jest insane ile mogą zmarnować kupując wyposażenie ich w te same komputery, z których korzysta Recepcjonista.

Dla kompilacji C#. Net, możesz użyć . Net Demon . Jest to produkt, który przejmuje proces tworzenia Visual Studio, aby go przyspieszyć.

Robi to analizując wprowadzone zmiany i buduje tylko projekt, który faktycznie zmieniłeś, a także inne projekty, które faktycznie polegały na wprowadzonych zmianach. Oznacza to, że jeśli zmienisz tylko kod wewnętrzny, musisz zbudować tylko jeden projekt.

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

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

Użyłem go na ogromnym rozwiązaniu C \ C++, które zwykle zajmuje 5-6 godzin, aby skompilować. IncrediBuild pomógł skrócić ten czas do 15 minut.

Instrukcje skrócenia czasu kompilacji w Visual Studio do kilku sekund

Visual Studio nie jest niestety wystarczająco inteligentny, aby odróżnić zmiany interfejsu zespołu od nieistotnych zmian ciała kodu. Fakt ten, w połączeniu z dużymi splecionymi rozwiązaniami, może czasami stworzyć idealną burzę niechcianych "pełnych kompilacji" prawie za każdym razem, gdy zmienisz pojedynczą linię kodu.

Strategia, aby to przezwyciężyć, polega na wyłączeniu automatycznych kompilacji drzewa referencyjnego. Na w tym celu użyj 'Configuration Manager' (Build / Configuration Manager...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 nie zaznaczaj pola wyboru 'Create new project configurations'. W tej nowej konfiguracji build odznacz każdy projekt, aby żaden z nich nie był budowany automatycznie. Zapisz tę konfigurację, naciskając "Zamknij". Ta nowa konfiguracja kompilacji jest dodawana do Twój plik rozwiązania.

Możesz przełączyć się z jednej konfiguracji kompilacji na inną za pomocą rozwijanej konfiguracji kompilacji u góry ekranu IDE (tego, który zwykle pokazuje "Debug" lub "Release"). Efektywnie ta nowa konfiguracja kompilacji ManualCompile sprawi, że opcje menu Build będą bezużyteczne dla: 'Build Solution' lub 'Rebuild Solution'. Tak więc, gdy jesteś w trybie ManualCompile, musisz ręcznie zbudować każdy projekt, który modyfikujesz, co można zrobić przez kliknij prawym przyciskiem myszy każdy projekt, którego dotyczy problem w Eksploratorze rozwiązań, a następnie wybierz opcję "Zbuduj" lub "Przebuduj". Powinieneś zobaczyć, że ogólny czas kompilacji będzie teraz zaledwie sekund.

Aby ta strategia zadziałała, konieczne jest, aby Numer wersji znajdujący się w plikach AssemblyInfo i GlobalAssemblyInfo pozostał statyczny na maszynie dewelopera (oczywiście nie podczas kompilacji wersji), a Ty nie podpisujesz swoich bibliotek DLL.

Potencjalne ryzyko stosowania tej strategii ManualCompile jest programista może zapomnieć o skompilowaniu wymaganych projektów, a po uruchomieniu debuggera uzyskuje nieoczekiwane wyniki (nie można dołączyć debuggera, nie znaleziono plików itp.). Aby tego uniknąć, najlepiej jest użyć konfiguracji' Debug', aby skompilować większy wysiłek kodowania i używać tylko ręcznej konfiguracji kompilacji podczas testowania jednostek lub do wprowadzania szybkich zmian, które mają ograniczony zakres.

Jeśli jest to C lub C++, a nie używasz wstępnie skompilowanych nagłówków, powinieneś.

Mieliśmy ponad 80 projektów w naszym głównym rozwiązaniu, które zajęło około 4 do 6 minut, w zależności od tego, jakiego rodzaju maszyny pracował programista. Uznaliśmy to za zbyt długie: dla każdego pojedynczego testu to naprawdę zżera Twoje EPC.

Jak uzyskać szybszy czas budowy? Jak wydaje się już wiesz, to liczba projektów, które naprawdę szkodzą czas budowy. Oczywiście nie chcieliśmy pozbyć się wszystkich naszych projektów i po prostu wrzucić wszystkie pliki źródłowe do jednego. Ale mieliśmy trochę projekty, które jednak mogliśmy połączyć: ponieważ każdy "projekt repozytorium" w rozwiązaniu miał swój własny projekt unittest, po prostu połączyliśmy wszystkie projekty unittest w jeden globalny projekt unittest. To zmniejszyło liczbę projektów z około 12 projektów 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 zawiera wszystkie pliki za pomocą folderów rozwiązania. Ponieważ możesz być zaskoczony, aby zobaczyć czas budowy tego nowego rozwiązania-z-tylko-jeden-projekt.

Jednak praca z dwoma różnymi rozwiązaniami będzie wymagała pewnej staranności. Deweloperzy mogą być skłonni do pracy w drugim rozwiązaniu i całkowicie zaniedbać pierwsze. Jako pierwsze rozwiązanie z ponad 70 projektami będzie rozwiązaniem, które dba o Twoją hierarchię obiektów, powinno to być rozwiązanie, w którym Twoja buildserver powinien uruchomić wszystkie Twoje unittesty. Tak więc serwer do ciągłej integracji musi być pierwszym projektem/rozwiązaniem. Musisz utrzymać swoją hierarchię obiektów.

Drugim rozwiązaniem z jednym projektem (który zbuduje się znacznie szybciej) będzie projekt, w którym Testowanie i debugowanie będą wykonywane przez wszystkich deweloperów. Musisz się nimi zająć patrząc na buildserver! Jeśli coś się zepsuje, trzeba to naprawić.

Upewnij się, że Twoje odniesienia są odniesieniami do projektu, a nie bezpośrednio do bibliotek DLL w katalogach wyjściowych biblioteki.

Również, mieć te ustawione, aby nie kopiować lokalnie, chyba że jest to absolutnie konieczne (master exe project).

I posted this response originally here: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 Na tej stronie znajdziesz wiele innych pomocnych wskazówek.

Jeśli używasz Visual Studio 2008, możesz kompilować używając flagi /MP, aby zbudować pojedynczy projekt równolegle. Czytałem, że jest to również nieudokumentowana funkcja w Visual Studio 2005, ale nigdy nie próbowałem.

Możesz budować wiele projektów równolegle używając flagi /m, ale to zazwyczaj jest już ustawiona na liczbę dostępnych rdzeni na maszynie, chociaż dotyczy to tylko VC++, jak sądzę.

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

Niektóre dodatkowe zasoby:

• https://stackoverflow.com/questions/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 - > VC++ project settings - > Build Timing = Yes powie Ci czas budowy dla każdego vcproj.

Dodaj {[0] } Przełącz do wiersza poleceń kompilatora, aby zobaczyć, ile zajmuje każdy plik CPP

Użyj /showIncludes, aby wyłapać zagnieżdżone includes( pliki nagłówkowe zawierające inne pliki nagłówkowe) i sprawdzić, które pliki mogą zapisać wiele IO za pomocą deklaracji forward.

Pomoże Ci to zoptymalizować wydajność kompilatora eliminując zależności i performance hogs.

Zanim wydasz pieniądze na inwestycje w szybsze dyski twarde, spróbuj zbudować swój projekt całkowicie na dysku RAM(zakładając, że masz pamięć RAM). Możesz znaleźć różne darmowe sterowniki dysków RAM w sieci. Nie znajdziesz żadnego dysku fizycznego, w tym dysków SSD, który jest szybszy niż dysk RAM.

W moim przypadku projekt, który zajął 5 minut, aby zbudować na 6-rdzeniowym i7 na 7200 RPM SATA Dysk z Incredibuild został zmniejszony o tylko około 15 sekund za pomocą dysku RAM. Biorąc pod uwagę potrzebę ponowne skopiowanie do pamięci trwałej i możliwość utraty pracy, 15 sekund to za mało motywacji do korzystania z dysku RAM i prawdopodobnie niewiele motywacji do wydawania kilkuset dolarów na dysk o wysokiej prędkości obrotowej lub SSD.

Mały zysk może wskazywać, że kompilacja była związana z CPU lub że buforowanie plików Windows było raczej skuteczne, ale ponieważ oba testy zostały wykonane ze stanu, w którym pliki nie były buforowane, pochylam się mocno w kierunku kompilacji związanych z CPU.

W zależności od rzeczywistego kodu jesteś obliczanie przebiegu może się różnić - więc nie wahaj się przetestować.

Jak duży jest Twój katalog budowania po wykonaniu pełnego kompilacji? Jeśli zachowasz domyślną konfigurację, to każdy zbudowany zestaw skopiuje wszystkie biblioteki DLL swoich zależności I zależności itp. do katalogu bin. W mojej poprzedniej pracy podczas pracy z rozwiązaniem ~40 projektów moi koledzy odkryli, że zdecydowanie najdroższą częścią procesu budowania było kopiowanie tych zestawów w kółko i w kółko, i że jedna kompilacja może generować gigabajty kopii ciągle te same biblioteki DLL.

Oto kilka przydatnych rad od Patrick Smacchia, autor NDepend, o tym, co jego zdaniem powinno i nie powinno być oddzielne Zgromadzenia:

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 zgromadzeń, co jest oczywiście dużo pracy. Innym jest restrukturyzacja Twoje katalogi buduj tak, aby wszystkie foldery bin były skonsolidowane, a projekty nie kopiowały bibliotek DLL ich zależności - nie muszą, ponieważ wszystkie są już w tym samym katalogu. To znacznie zmniejsza liczbę plików utworzonych i skopiowanych podczas kompilacji, ale może być trudne do skonfigurowania i może sprawić, że z trudem wyciągniesz tylko biblioteki DLL wymagane przez konkretny program wykonywalny do pakowania.

Być może weź kilka wspólnych funkcji i stwórz kilka bibliotek, w ten sposób te same źródła nie są kompilowane w kółko dla wielu projektów.

Jeśli obawiasz się, że różne wersje bibliotek DLL się pomieszają, użyj bibliotek statycznych.

Wyłącz integrację VSS. Możesz nie mieć wyboru w używaniu go, ale biblioteki DLL zostają "przypadkowo" przemianowane przez cały czas...

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

Mam projekt, który ma 120 lub więcej exe, libs i DLL i zajmuje sporo czasu, aby zbudować. Używam drzewa plików wsadowych, które wywołują pliki make z jednego głównego pliku wsadowego. Miałem problemy z dziwnymi rzeczami z przyrostowych (lub był Temperamentny) nagłówków w przeszłości, więc unikam ich teraz. Robię pełny build rzadko, i zwykle zostawiam go do końca dnia, podczas gdy idę na spacer na godzinę (więc mogę się tylko domyślać, że trwa to około pół godziny). Więc rozumiem, dlaczego to jest nie nadaje się do 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. Od czasu do czasu mogę przełączać DEBUG on of off, a także decydować o buildach lub markach lub 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ń kończy się to w ciągu kilku sekund do minuty (w przeciwieństwie do powiedzmy pół godziny).

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

Chętnie zamieszczę 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 twoje źródło mogło być przeszukiwane)

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

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

Możesz znaleźć przegląd tutaj: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Możesz również sprawdzić odniesienia do projektów okrągłych. Kiedyś to było dla mnie problemem.

Czyli:

Projekt a referencje projekt B

Projekt B referencje Projekt C

Projekt C referencje Projekt A

Tańszą alternatywą dla Xoreax IB jest użycie tego, co nazywam Uber-file builds. To w zasadzie A.plik cpp, który ma

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

Następnie kompilujesz jednostki Ubera zamiast poszczególnych modułów. Widzieliśmy czasy kompilacji od 10-15 minut do 1-2 minut. Być może będziesz musiał doświadczyć, ile #zawiera każdy plik Ubera ma sens. Zależy od projektów. itd. Może załączysz 10 plików, może 20.

Płacisz koszty więc uważaj:

1. You can ' T kliknij prawym przyciskiem myszy plik i powiedz " compile..."ponieważ musisz wykluczyć pojedyncze pliki cpp z kompilacji i dołączyć tylko pliki uber cpp
2. Należy uważać na statyczne konflikty zmiennych globalnych.
3. po dodaniu nowych modułów, musisz aktualizować pliki Ubera

To rodzaj bólu, ale dla projektu, który jest w dużej mierze statyczny pod względem nowych modułów, ból intial może być tego wart. Widziałem tę metodę pokonać IB w niektórych przypadkach.

Jeśli jest to projekt C++, powinieneś używać wstępnie skompilowanych nagłówków. To sprawia ogromną różnicę w czasie kompilacji. Nie wiem, co cl.exe naprawdę robi (nie używając wstępnie skompilowanych nagłówków), wydaje się, że szuka partii nagłówków STL we wszystkich niewłaściwych miejscach, zanim w końcu trafi do właściwej lokalizacji. To dodaje całe sekundy do każdego .plik cpp jest kompilowany. Nie wiem, czy to jest cl.błąd exe, albo jakiś problem z STL w VS2008.

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

Właśnie zmniejszyliśmy czas kompilacji naszego największego produktu w skali C++ z 19 godzin do 16 minut, upewniając się, że zainstalowany został odpowiedni sterownik filtra SATA.

Subtelne.

Jest nieudokumentowany / MP switch w Visual Studio 2005, zobacz http://lahsiv.net/blog/?p=40 , które umożliwiałyby kompilację równoległą na podstawie plików, a nie na podstawie projektu. Może to przyspieszyć kompilację ostatniego projektu lub, jeśli skompilujesz jeden projekt.

Wybór rozmiaru pamięci podręcznej CPU: L1 wydaje się mieć ogromny wpływ na czas kompilacji. Ponadto zwykle lepiej jest mieć 2 szybkie rdzenie niż 4 wolne. Visual Studio nie używa dodatkowych rdzeni bardzo skutecznie. (Opieram to na moich doświadczeniach z kompilatorem C++, ale prawdopodobnie dotyczy to również C# one.)

Jestem również przekonany, że jest problem z VS2008. Uruchamiam go na dwurdzeniowym laptopie Intel z 3G Ram, z wyłączonym antywirusem. Kompilowanie rozwiązania jest często dość sprytne, ale jeśli debugowałem kolejną rekompilację, często spowolni to do indeksowania. Z ciągłego światła głównego dysku jasno wynika, że jest wąskie gardło wejścia/Wyjścia dysku (słychać to też). Jeśli anuluję kompilację i zamknięcie VS aktywność dysku zatrzymuje się. Restart VS, przeładuj rozwiązanie, a następnie Odbuduj, i to jest znacznie szybsze. Unitl the next time

Moje myśli są takie, że jest to problem z przywoływaniem pamięci - VS po prostu kończy się pamięć i O / S zaczyna wymieniać strony, aby spróbować zrobić miejsce, ale VS wymaga więcej niż wymiana stron może dostarczyć, więc spowalnia do indeksowania. Nie mogę wymyślić innego wyjaśnienia.

VS zdecydowanie nie jest narzędziem RAD, prawda?

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

Miłe 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 przeczytać wtedy, tylko to, co nam pomogło)

[[3]] Nowy laptop 3GHz-potęga utraconego wykorzystania działa cuda, gdy do zarządzania
• wyłączanie antywirusa podczas kompilacji
• 'odłączanie' od VSS (właściwie sieci) podczas kompilacji - może nam się uda usunąć integrację VS-VSS i trzymać się używania VSS UI

Nadal nie rip-wciąganie przez kompilację, ale każdy bit pomaga.

Testujemy również praktykę budowania nowych obszarów aplikacji w nowych rozwiązaniach, importując w miarę potrzeb najnowsze biblioteki DLL, integrując je w większe rozwiązanie, 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 zamykają obszary, nad którymi musimy pracować, i wyrzucając je po reintegracji kodu. My trzeba rozważyć czas potrzebny na reintegrację tego kodu z czasem, który zyskujemy, nie mając podobnych doświadczeń Rip Van Winkle z szybką rekompilacją podczas rozwoju.

Orion wspomniał w komentarzu, że generyki mogą mieć również grę. Z moich testów wynika, że osiągi są minimalne, ale nie wystarczająco wysokie, aby być pewnym - czasy kompilacji mogą być niespójne ze względu na aktywność płyty. Ze względu na ograniczenia czasowe, moje testy nie zawierały tak wielu generyków, ani tak dużo kodu, jak pojawi się w systemie live, więc może się kumulować. Nie unikałbym używania generyków tam, gdzie powinny być używane, tylko dla wydajności w czasie kompilacji

Jest kilka rzeczy, które uznałem za przydatne do budowania C#/. Net:

• Połącz małe projekty w większe projekty, ponieważ istnieje duży narzut na projekt na budowanie rozwiązania. (Użyj nDepend w razie potrzeby do sterowania wywołaniem między warstwami)

• Upewnij się, że wszystkie nasze projekty są wbudowane w jakiś katalog wyjściowy, a następnie Ustaw "copy local" NA false we wszystkich referencjach do projektu – może to prowadzić do dużej prędkości ze względu na zmniejszenie IO.

• Jeśli tak, znajdź szybszy program do sprawdzania wirusów, lub wyklucz foldery "gorące" ze skanowania antywirusowego

• Użyj monitora perforce i wewnętrznego narzędzia sys, aby zobaczyć, jak twoje Kompilacje trwają tak długo.

• Rozważ dysk ram, aby umieścić swój katalog wyjściowy.

• Rozważ użycie dysku SSD

• Więcej pamięci może czasami mieć duży wpływ – (zmniejsz pamięć ram w maszynie jeśli uzyskasz duże spowolnienie, usuwając trochę pamięci ram, możesz uzyskać dużą prędkość, dodając więcej) Usuń niepotrzebne odniesienia do projektu (być może będziesz musiał najpierw usunąć niepotrzebne "zastosowania")

• Rozważ użycie frameworka iniekcji zależności i interfejsów dla najniższej warstwy domeny, więc przekompilowanie wszystkiego jest potrzebne tylko wtedy, gdy interfejs się zmienia – może to niewiele zyskać w zależności od tego, jak często interfejs jest zmieniany.