2012-05-09 49 views
11

Mój Xcode zaczął zachowywać się bardzo mocno od wczoraj podczas pracy nad projektem średniej wielkości (około 200 plików źródłowych). Projekt poprawnie się kompiluje i działa zarówno na symulatorze, jak i na urządzeniu. Nie używam żadnych bibliotek stron trzecich, z wyjątkiem niewielu powszechnie używanych rozszerzeń (takich jak JSON lub facebook ios sdk).Xcode 4.3.2 i 100% CPU stale w stanie bezczynności

Ciągle wykorzystuje procesor (y) przy pełnej prędkości, nawet jeśli jest w stanie bezczynności (brak indeksowania, brak kompilacji, brak edycji). Korzystanie z pamięci RAM jest stosunkowo normalne (300-50 MB).

Moja maszyna wykorzystuje: procesor Core 2 Duo 3.04 GHz, 8 GB pamięci RAM i napęd OCZ 3 w formacie Vertex OCZ.

Próbowałem każde proponowane rozwiązanie znaleźć na stackoverflow:

  1. Oczyszczone projektu
  2. czyszczone Odczytane dane organizator
  3. Oczyszczone repozytoria organizator
  4. Oczyszczone xcodeproject bundle od obszaru roboczego i userData plików jako sugerowanego tutaj: https://stackoverflow.com/a/8165886/229229 (pomaga to na chwilę i zaczyna się ponownie po minucie lub trochę).
  5. Zrestartowano Xcode wiele razy (z tym samym efektem co w 4).
  6. niepełnosprawnych "na żywo" kwestie
  7. nawet ponownej instalacji Xcode

Nic nie pomaga. W większości przypadków Xcode indeksuje projekt przez chwilę, a następnie wraca do normalnej wydajności, ale po chwili staje się bezużyteczny ponownie. CPU powraca do 95-100% dla obu rdzeni wisi wywiadu, itp ...

Załączam zrzuty ekranu jak procesy Xcode postrzegane są przez instrumenty:

enter image description here enter image description here enter image description here enter image description here enter image description here

UPDATE: Po chwili nadziei, że rozwiązał ten problem porusza kilka

#import "header.h"

oświadczenia nagłówki do plików wykonawczych i wymieniając je z przodu deklaracji ... problem powrócił ponownie po pewnym czasie. Dodaję dziennik konsoli. Dziwne jest to, że logi związane z Xcode pojawiają się po tym, jak go opuściłem, a nie podczas uruchamiania itsef.

dzienniki konsoli:

5/11/12 9:27:03.777 AM [0x0-0x45045].com.apple.dt.Xcode: com.apple.dt.instruments.backgroundinstruments: Already loaded 
5/11/12 9:27:05.571 AM Xcode: Performance: Please update this scripting addition to supply a value for ThreadSafe for each event handler: "/Library/ScriptingAdditions/SIMBL.osax" 
5/11/12 9:27:58.168 AM Xcode: ERROR: Failed to create an alert for ID "enabled" based on defaults: 1 
+0

Co z innymi projektami? Czy zachowuje się w ten sam sposób? –

+1

Domyślam się, że masz jeden plik lub jeden zestaw plików, który sprawia, że ​​analiza składniowa potrzebna do podświetlania składni, uzupełniania kodu itp. Przechodzi w nieskończoną pętlę (co byłoby błędem). Może 'lsof' może ci powiedzieć, nad którym plikiem pracuje. Użyj 'lsof -p ', aby sprawdzić działający proces. – mvds

+0

@Ondra Peterka: Nie, zachowuje się tylko w ten sposób. – Lukasz

Odpowiedz

5

Co zatrzymał mój koszmar:

  1. Zmień Zawsze Ścieżka wyszukiwania użytkownika do NO w projekcie budowy ustawień (pogrubione).
  2. Usuń -objC flag Inne flagi Linker (również pogrubione ustawienie).

A następnie usuń dane pochodne i poczekaj na ponowne indeksy Xcode.

Nie jestem pewien, które z nich pomogły, ponieważ zmieniłem ich obu w tym samym czasie i jestem tak blisko mojego harmonogramu, że nie mam czasu, aby go przetestować. Poprawię tę odpowiedź, kiedy powtórzę błąd i rozwiązanie w wolnym czasie.

Jednakże, istnieje wskazówka: * Rethink i ponownie sprawdzić swój projekt/cele budować ustawienia. *

Jest wysoce prawdopodobne, że to dziwne zachowanie może być spowodowane przez niefortunną kombinację ustawień kompilacji.

+0

w moim przypadku była to zawsze szukana ścieżka użytkownika, dzięki! –

+0

Mogłem po prostu usunąć flagę -objC i all_load z innych znaczników linkera, ścieżka użytkownika zawsze znajdowała się już na NIE. Sądzę więc, że jest to połączenie obu. Dziękuję Ci. – Charles

+1

Usuwanie -objC działało jak magia dla mnie – eckyzero

1

Wygląda na to, że spędza swój czas parsowania ObjC zawarte w PCH.

  • Ile PCH musi zadzwonić? W twoim projekcie byłby to jeden dla C, jeden dla ObjC, jeden dla C++, jeden dla ObjC++ dla każdego dialektu/języka używanego w projekcie i dla dowolnych zależnych celów.To znaczy - jeśli masz bibliotekę zależną zawartą w PCH twojej aplikacji i hakujesz w tej bibliotece, cały sens kodu w miejscu docelowym aplikacji musi zostać unieważniony i ponownie przeanalizowany za każdym razem, gdy zmienisz nagłówek dołączony do pch. A jeśli twój cel kompiluje plik C, będzie potrzebował PCH dla C. Jeśli potrzebuje go dla ObjC, będzie musiał wygenerować jeden dla ObjC.
  • Jak często zmieniasz PCH (lub cokolwiek w nim zawartego)?
  • Usuń zawiera z PCH. Nie jest niczym niezwykłym widzieć każdą połączoną strukturę zawartą w PCH (unikaj tego!).
  • Po zmianie ustawień kompilacji lub preprocesora może zaistnieć potrzeba ponownego zbudowania indeksu wykrywania kodu dla celu (ów) całkowicie za każdym razem.
  • Czy próbowałeś wyłączyć problemy na żywo?
+0

Wyłączenie problemów na żywo również nie pomogło. Nie zmieniam często PCH. Dodałem do niego tylko Constants.h (zawiera tylko niektóre #define (s)), ale było to dawno temu i projekt zachowywał się ładnie długo po tym. – Lukasz

+0

Głosuję w tej sprawie, ponieważ zwróciła mi uwagę na ponowne sprawdzenie i przeprojektowanie obejmujące ścieżki struktury i wyszukiwania, które wydawały się pomagać. – Lukasz

0

Na moich projektach (wszystkie z nich) był to autouzupełnianie/intellisense. Kiedy zmieniłem jedną linię kodu w moich plikach .h, poszło wściekłość, + 100% użycia procesora (więcej niż jeden rdzeń). Po prostu wyłączam to, teraz muszę myśleć trochę więcej dla siebie (jak to robiłem w Windows) i działa świetnie przy niskim zużyciu procesora.

3

Wszystkie moje projekty robią to od czasu do czasu. Mogę wyłączyć kod X i uruchomić go ponownie i będzie działał dobrze przez jakiś czas, a następnie wrócić do korzystania z 200% czasu procesora (dwa w pełni załadowane rdzenie).

Moje rozwiązanie polega na użyciu AppCode jako mojego podstawowego IDE (ma dodatkową zaletę, że jest znacznie lepszym IDE, ale to już inna historia). Uruchamiam XCode tylko wtedy, gdy muszę edytować storyboardy i wyłączam je, kiedy skończę - zwykle to zapobiega problemowi.

AppCode uruchamia te same pliki/struktury projektu, ma lepsze i szybsze indeksowanie i nigdy nie jest uruchamiany w tym wydaniu, więc nie widzę, jak może to być problem z ustawieniami/konfiguracją - musi to być błąd w XCode. Dlatego nie traciłbym czasu na zmianę struktury kodu, ponieważ najprawdopodobniej opóźni to problem, a nie go naprawi.

-1

Zwykłem napotkać ten problem.To jest spowodowane przez git.Although nie wiem, git bardzo well.i usunął plik o nazwie .git w katalogu projektu i okazało się, że normalnie. .git jest ukryty.

2

Nie wiadomo, czy OP miał inną przyczynę, ale wydaje mi się, że był to usterka Xcode z git. Dodawanie/zatwierdzanie moich bieżących zmian rozwiązało mój problem. Oto pełna scenariusz i co zrobiłem, aby to naprawić:

  • Środowisko:
    • Xcode Version 5.1.1 (5B1008)
    • Macbook Pro OS X 10.9.2
    • 2 GHz Intel Core i7, 8 GB RAM
  • Zauważyłem, że Xcode zaczynał jeść % mojego procesora.
  • Nie wiem dokładnie, kiedy to się zaczęło, ale Xcode nie zamarznąć na próbuje zrobić zdjęcie (400% wykorzystania procesora przez kilka minut, dopóki nie zmusi-quitted Xcode)
  • Po ponownym otwarciu zauważyłem Xcode wciąż tkwi w nieskończoność na % Użycie procesora.
  • Zamknięcie wszystkich projektów nie działa.
  • Usunięcie wszystkich danych pochodnych i ponowne uruchomienie nie działa.
  • Odinstalowanie Xcode i ponowne zainstalowanie na pierwszym dotrzymanym obietnicy, ale po ponownym otwarciu głównego projektu CPU powróciło do stałego zużycia % procesora. (po zakończeniu indeksowania)
  • Zamknięcie projektu związanego z kłopotami nie pomogło. Xcode utknął ponownie na ziemi zabijającej 200% mocy procesora.

Po obejrzeniu Stack przepełnienia, wielu ludzi nawiązywało do git będącego problemem.

  • Mam nieco skomplikowane repozytorium git (ma repozytorium częściowe i podprojekt w głównym projekcie Xcode).
  • Miałem oczekujące zmiany zarówno w głównym repozytorium, jak i w module częściowym repo.
  • Zamknąłem Xcode i git dodał & popełnił wszystkie moje bieżące zmiany.
  • Ponownie otwórz Xcode i VIOLA! Koniec z zabijaniem procesora. Powrót do wartości 0.0% bezczynności.

Xcode 5.1.x wydaje się również walczyć z git w inny sposób dla mnie też (czasami nie odbiera zmian w GUI, itp.), Więc być może są błędy integracji Xcode git.

+0

Dzięki temu rozwiązało to dla mnie. Zatwierdzenie moich zmian spowodowało, że Xcode przestał przetwarzać/indeksować. Xcode 7.3.1 i OS X 10.11.5. Mój xcodeproject jest mieszany swift/objc dla iOS, wykorzystuje cartage i osadza kilka frameworków. – neoneye

Powiązane problemy