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.