Dlaczego xcodebuild i Xcode 4.2 są tak powolne?

Większość z nas ma trzy podstawowe opcje:

• wróć do Xcode 3 dla codziennego rozwoju.
Rzuć więcej sprzętu.
• Zmień struktury swoich projektów i zastosuj sztuczki programistyczne na dużą skalę (nawet jeśli 20-30 KSLOC nie jest duże).

Najprostszym rozwiązaniem jest powrót do Xc3. Tak, Xc4 wymaga partii więcej niż XC3; Pamięci, PROCESORA i miejsca na dysku oraz wejścia / Wyjścia. wpływa na Ciebie.

Przejście na Lion + Xc4 ponad dwukrotnie zwiększyło moje wymagania sprzętowe we wszystkich z następujących kategorii:

Pamięć

4GB to teraz za mało dla większości nietrywialnych projektów korzystających z Xc4 i Lion. Nadal możesz to zmniejszyć. Mam 8GB i 10GB na moich głównych maszynach 2, Xc4 zużywa to wszystko dość łatwo (ale moje projekty są bardziej złożone niż Twoje, chyba że piszesz reeaaaaardzo długie linie). W każdym razie, możesz zmniejszyć ten problem przez:

Kupując więcej pamięci.
• Wyłącz indeksowanie, jeśli budujesz ogromne projekty w Xcode. To może o połowę zużycie pamięci Xcode.
• uruchamianie Xcode w 32 bitach. Nie jest to opcja dla wszystkich, ponieważ przekroczy 4 GB w większych projektach.
• zmniejsz liczbę procesów budowania (ponownie).
• ponowne uruchamianie Xcode często(nie robi zbyt dobrej roboty sprzątanie po sobie).
• Użyj clang jako kompilatora. Instancje Clang na ogół zużywają mniej pamięci niż Apple GCC 4.2.
• Odciążaj zależne od siebie cele, które nie zmieniają się często. Przykład: będziesz w większości przypadków nie trzeba odbudowywać bibliotek stron trzecich codziennie.

CPU

Xcode 4 używa nowego (dokładniejszego) parsera dopełnienia.

• sparuj swoje wykresy zależności I zależności. Jest to dość łatwe w przypadku Obj-C, ponieważ każda instancja Obj-C jest wskaźnikiem. Przykład: usuń luźno zależne Framework includes z nagłówków.
• odpowiednio oddziel zależności i moduły. Rozwijaj biblioteki, ale staraj się, aby były dość małe i bądź świadomy zależności, które dodadzą. Przykład: prowadzę projekt, w którym dev dodał małą funkcjonalność (mniej niż 1% aplikacji), ale ze względu na wymaganą liczbę zależności (np. Three20, a następnie kilka innych), Rozmiar binarny finalnego pliku wykonywalnego podwoił się (i czasy budowania poszły w górę, a parser miał dużo więcej pracy). Większość z nich nie była potrzebna do funkcji-po prostu nie można ich było rozebrać, ponieważ były symbolami objec.
• zmniejsz liczbę tłumaczeń, jeśli możliwe.
• zoptymalizuj sposób używania nagłówków przedrostków. Możesz je udostępniać i tworzyć bez dobrego powodu. Jest to bardziej korzystne dla kompilatora niż IDE.
• zminimalizuj zużycie pamięci. GC work (w tym wszystkie NSObject allocs) zużywa ponad 1/3 zużycia procesora w większych projektach, ale nadal spędza dużo czasu na zbieraniu, gdy jego sterta jest ogromna.
• Użyj zewnętrznych edytorów tekstu i klientów VC. Dość oczywiste, ponieważ Xc4 wyświetla SBBOD dość często w dużych projekty.
• zminimalizuj złożoność języka. W kolejności złożoności: C, ObjC, C++, ObjC++. Im bardziej złożone tłumaczenia, tym dłużej zajmie parsowanie i kompilowanie źródeł, zwłaszcza gdy zależności są wysokie. Jeśli możesz łatwo skonfigurować bariery językowe w zależności, zrób to.
• Możesz wyłączyć indeksowanie funkcji code sense poprzez defaults (zmniejsza również zapotrzebowanie na pamięć).

Dysk Twardy

Może to być Prędkość / rozmiar równowaga.

• kup szybszy (np. SSD).
• Czyszczenie i minimalizacja zależności nagłówka.
• Użyj dysku RAM, np. Utwórz dysk RAM .
Kup więcej pamięci. Z ilością zużywaną przez Xc4, kończy się to zamianą na dysk często w dużych projektach.
• Zoptymalizuj swoje Kompilacje, aby odpowiednio używać plików pch. Nie zawsze jest to oczywisty kierunek: nie korzystam z nich od kilku lat w dużych projektach.
• Wyczyść pliki tymczasowe Xcode i Instrumenty pozostawiają po sobie, mogą być ogromne . W niektórych przypadkach można je zapisać w niestandardowych lokalizacjach. Jeśli zużywają dziesiątki GB, a Katalog kompilacji jest taki sam jak katalog rozruchowy, sprawisz, że dysk będzie działał znacznie mniej, regularnie czyszcząc go.

Buduje

• W Xc4, xcodebuild równoległy do Xcode teraz podwaja pracę(oddzielne dirs kompilacji domyślnie). W Xc3 domyślne było budowanie do tego samego miejsca docelowego. Zweryfikuj swoje ustawienia - Xcode zrobi mnóstwo nadmiarowego budynku, jeśli na to pozwolisz(np. jeden cel na obszar roboczy / config, a nie płaski model Xc3).

• Możesz też wypełnić szufladę czterordzeniowymi MacMinis i użyć go jako dedykowanego lub rozproszonego konstruktora.

File Bugs

(samo wyjaśniające)