Xcode 4 - performances lentes

J'ai un problème avec Xcode 4 qui répond vraiment très lentement aux interactions des utilisateurs, par exemple l'édition de code, les zones de défilement, etc. Cela se produit particulièrement avec des projets à plus grande échelle avec de nombreux contrôleurs / fichiers de vue, etc.

J'ai complètement essuyé le disque dur et réinstallé Snow Leopard et Xcode l'autre semaine, mais le temps de réponse est à nouveau frustrant (sur plusieurs jours) perturbant considérablement le flux de travail.

J'ai aussi parfois supprimé les "données dérivées" du projet via l'Organisateur -> Projets et cela n'a eu que peu d'effet.

Je me demande s'il y a quelque chose que je puisse faire pour améliorer les performances autre que d'obtenir une machine plus performante en premier lieu.

Pour info, j'utilise un MacBook avec des processeurs Intel Core 2 Duo à 2 GHz et 4 Go de RAM.

Au cas où nous aurions besoin de mettre à niveau, j'aimerais également savoir si les gens rencontrent ces mauvaises performances de Xcode 4 sur des machines bien spécifiées (ce qui rendrait notre mise à niveau matérielle plutôt inutile car c'est seulement Xcode qui a des problèmes de performances sur le MacBook).

Si quelqu'un a des suggestions ou des recommandations ou pourrait même nous faire savoir comment l'amélioration du matériel affecte les performances de Xcode sur des arborescences de projets plus grandes, cela serait extrêmement utile et également une ressource précieuse pour d'autres développeurs dans une position similaire.

Si vous purgez le fichier de l'espace de travail, cela permet de l'accélérer.

Tout d'abord, assurez-vous que Xcode n'est pas ouvert. Recherchez maintenant votre fichier de projet. Cliquez dessus avec le bouton droit de la souris et sélectionnez Show Package Contents.

Ensuite, supprimez project.xcworkspace.

Ouvrez Xcode et profitez de performances plus rapides!

Merci à: http://meachware.blogspot.com/2011/06/speed-up-xcode-4.html

Edit: J'ai reçu plusieurs commentaires à ce sujet, notant que pour certains projets, cela pourrait poser des problèmes. Assurez-vous d'avoir une sauvegarde de votre projet avant d'effectuer ces étapes, et n'oubliez pas de vérifier et de tester votre projet par la suite . Assurez-vous que vous avez toujours tous vos exécutables et schémas.

MISE À JOUR IMPORTANTE: Les chemins ont changé pour Xcode 6 (Merci pour le commentaire dcc)! Je viens d'ajouter la manière alternative.

Il existe une autre astuce intéressante pour fixer les builds en créant un disque RAM avec la ligne de code suivante:

diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://8475854`

Cela crée une image disque en mémoire d'une taille d'environ 4 Go. Mais attention, vous devez avoir suffisamment de mémoire. Bien sûr, vous pouvez créer une image plus petite comme 2 Go (ce serait 4237927).

Ensuite, vous dites à Xcode d'y stocker les données dérivées

Vous ne pouvez pas dire à Xcode d'y stocker directement les données de l'iPhone Simulator, mais vous pouvez créer un dossier sur le disque virtuel et créer un lien symbolique au lieu du répertoire iPhone Simulator en procédant comme suit:

Xcode 6:

cd /Volumes/ramdisk
mkdir CoreSimulator
rm -R ~/Library/Developer/CoreSimulator
ln -s /Volumes/ramdisk/CoreSimulator ~/Library/Developer/CoreSimulator

Anciennes versions de Xcode:

cd /Volumes/ramdisk
mkdir iPhone\ Simulator
rm -R ~/Library/Application\ Support/iPhone\ Simulator
ln -s /Volumes/ramdisk/iPhone\ Simulator ~/Library/Application\ Support/iPhone\ Simulator

Si je construis pour le simulateur avec cette configuration, il est opérationnel en un rien de temps :)

Sachez que le disque RAM disparaîtra lorsque vous redémarrerez votre machine, il peut donc être judicieux de créer un script ou quelque chose qui s'exécute au démarrage. ET NE PLACEZ PAS LES DONNÉES QUE VOUS VOULEZ CONSERVER !!!

MISE À JOUR 12/03/2013:

1. Lisez le commentaire de Francisco Garcia ci-dessous!

2. Avec mon nouveau MBP (contenant un disque SSD), je n'ai plus besoin de cette méthode. Xcode fonctionne comme un enfer :). J'espère que ce n'est pas considéré comme une publicité pour le gros fruit, c'est juste un rapport d'expérience ...

La désactivation des problèmes en direct dans les préférences générales a fait une nette différence. J'ai également configuré un schéma sans gdb activé pour les situations où je réexécute fréquemment (aucun gdb n'accélère un peu le lancement).

Pour moi, Xcode a obtenu une énorme augmentation des performances après l'avoir configuré pour fonctionner en mode 32 bits (il était de 64 par défaut). Il est presque aussi rapide que l'ancien Xcode 3. Vous pouvez passer en 32 bits en cliquant avec le bouton droit sur l'application (dans /Developer/Applications/XCode.app ) et en sélectionnant Obtenir des informations et en cochant Ouvrir en mode 32 bits .

Xcode 4.2, 4.3:

Problèmes majeurs avec l'indexeur de fichiers (même code qui exécute Spotlight, qui a été bogué pendant des années? Probablement).

Désactivez tout ce qui n'est pas essentiel lié à la "surveillance" des fichiers:

1. Aide rapide (NB: ne cliquez jamais sur l'onglet QH! Même le fait de cacher l'assistant entraîne toujours l'exécution du code! Passez à un autre onglet avant de passer à un nouveau fichier ...)
2. Gestion SCM (SVN, Git, etc. - Le support git de Xcode est encore un peu bogué (peut corrompre les projets), et ils ont abandonné le support SVN, vous ne devriez donc pas l'utiliser de toute façon!)
3. essayez de supprimer votre dossier d'espace de travail (selon la réponse acceptée), mais uniquement s'il est volumineux sur le disque
4. ... tout ce que vous pouvez trouver concernant l'état des fichiers individuels

Xcode 4.4, 4.5:

Ces versions ont une fuite importante de mémoire, un indexeur de fichiers cassé (mais mieux que 4.2 et 4.3), et peut-être un problème de fichier d'échange privé.

Finalement, en désactivant / activant l'espace d'échange ( comment désactiver ou activer l'échange sous mac os x ), et en utilisant des disques durs normaux sur plusieurs machines, et en exécutant des expériences sur des machines avec 2 Go de RAM jusqu'à 16 Go de RAM, j'ai trouvé que Xcode semble exécuter son propre espace d'échange, indépendant du swap OS X (!).

(cela pourrait être une erreur - il existe peut-être une forme supplémentaire d'échange d'OS X que je ne connais pas - mais les fichiers d'échange système ne sont pas devenus plus gros ou plus petits, tandis que l'espace disque a bondi de gigaoctets de haut en bas sur certaines machines)

Observé:

1. Xcode 4.4 / 4.5 prendra aléatoirement toute la RAM de votre système (10 de Go pour un petit projet) afin que le reste du système s'arrête, coincé en attendant l'échange de disque

   1. Pire: sur les macbooks avec SSD, vous ne saurez pas que cela s'est produit
   2. PIRE: ... même si cela peut endommager votre disque dur (les SSD n'aiment pas écraser les écritures)

2. Xcode va monopoliser l'accès au disque dur afin de pouvoir effectuer son indexation de fichier interne (cassée). Lorsque la mémoire système est faible et que OS X doit effectuer un échange ... il reste bloqué en attendant que Xcode indexe les fichiers ... et Xcode prend plus de mémoire pendant qu'il attend ... et: BOOM! sur les systèmes plus petits, OS X se bloque finalement

3. Xcode n'a pas besoin d'espace de swap OS X

Le dernier est très intéressant. Si vous disposez de beaucoup de mémoire (par exemple 16 Go), essayez de désactiver définitivement l'espace d'échange. Xcode s'exécute plus rapidement, car OS X Lion a quelques bogues dans la gestion des mémoires où il échange même lorsqu'il n'en a pas besoin .

Si xcode ralentit soudainement, il échange en interne, à quel point vous pouvez simplement le tuer et le redémarrer.

(si vous avez un SSD, le seul moyen de savoir si son échange a commencé est d'attendre qu'il "ralentisse". Sinon, vous savez dès que vous entendez le thrash HD: il n'y a plus de fichier d'échange système, donc le la seule cause possible est Xcode)

Vous pouvez désactiver le swap en toute sécurité même si vous avez 2 Go de RAM (je n'ai eu qu'un seul crash OS X par mois lorsque j'ai essayé cela, je l'ai exécuté de cette façon pendant un an), mais cela vous empêchera de faire du travail vidéo / graphique haut de gamme avec des fichiers qui ont besoin de plusieurs gigaoctets pour fonctionner. N'hésitez pas à l'essayer pendant quelques semaines et voyez ce qui se passe.

Mais ... redémarrer Xcode chaque fois qu'il ralentit fait des merveilles. Sur les machines avec moins de RAM, le fichier d'échange privé de Xcode semble être IMMÉDIATEMENT supprimé lorsque vous fermez (cela ne semble pas se produire sur les machines avec beaucoup de RAM)

Aucune de ces réponses n'a vraiment amélioré les performances dans mon cas (avec le temps, Xcode 4.1 est devenu à peine utilisable, le quitter de temps en temps a aidé).

Cependant, je viens de découvrir que si je continue à fermer tous mes documents (contrôle-commande-W), cela semble rester rapide. Xcode conserve automatiquement tous les documents sur lesquels vous cliquez en mémoire d'une manière ou d'une autre, et vous pouvez naviguer entre eux avec la flèche gauche / droite de la commande de contrôle. Si vous en ouvrez accidentellement trop (notamment les fenêtres IB), il s'arrête. La simple fermeture de tous les documents ouverts de temps en temps semble atténuer ce problème sans qu'il soit nécessaire de redémarrer complètement.

Le message suivant de @lukasz a un peu aidé, en particulier son élément n ° 8 dans sa réponse (Panneau utilitaire fermé et volet d'aide rapide)

Xcode 4 est devenu extrêmement lent et tue mon disque dur

Tous ceux qui rencontrent ces problèmes devraient essayer Xcode 4.1 sur Mac OS X Lion. Je suis surpris de voir à quel point il est plus rapide et réactif sur le même matériel (Macbook Pro 2,66 GHz Core 2 Duo avec 4 Go de RAM ici).

Je suppose qu'ils ont corrigé des tonnes de bugs de performances avec cette version.

Lancez les Instruments avec le modèle de profil temporel et attachez-le au Xcode en cours d'exécution (ou clang, llvm, etc. si votre problème se situe pendant les builds). Vous devriez être en mesure de voir le problème assez rapidement. J'ai vu des causes très différentes sur différentes machines. Le contrôle de version est souvent un coupable.

Je suis confronté aux mêmes problèmes. Ils ont été en partie corrigés car les versions bêta sont toujours persistantes. Il semble que Xcode ait en interne une ou plusieurs fuites qui flottent dans votre mémoire. Vous pouvez très bien regarder cette "fonctionnalité" astucieuse lorsque vous utilisez l'Interface-Builder intégré. Deux solutions possibles sous prier et remplir des rapports de bogues à Apple:

1. N'utilisez pas de générateur interne, lancez plutôt l'application externe.
2. Quittez Xcode de temps en temps, cela devrait libérer la mémoire qui a fui.

J'ai essayé à peu près tout ce qui a été suggéré dans ce fil et [de nombreux] autres et la seule chose qui a fonctionné pour moi était de "désactiver" la subversion pour le projet. Voici la partie merdique - la SEULE façon dont je pouvais "désactiver" le plugin SVN intégré était de fouiller mon fichier / etc / hosts avec une fausse adresse IP, provoquant ainsi l'échec de tous les accès SVN.

J'ai essayé de supprimer / renommer IDESubversion.ideplugin dans / Developer / Library / Xcode / PrivatePlugIns, mais Xcode 4.2.1 vomit et refuse de démarrer.

J'ai essayé de supprimer mes référentiels SVN de Xcode à chaque fois que je redémarre Xcode, mais Xcode plante en quelques minutes.

J'ai essayé de désactiver "Remote Status" via File-> Source Control-> Hide Remote Status (n'a rien fait pour moi).

Maintenant que j'ai défini mon nom d'hôte SVN sur 1.2.3.4 dans mon fichier hosts, Xcode fonctionne très bien et n'affiche pas le SBBOD presque chaque fois que je passe d'un fichier à l'autre.

$ grep 1.2.3.4 /etc/hosts
1.2.3.4 svn.myhost.com

Ensuite, quand je veux vraiment faire le contrôle de version, je dois décompresser le fichier hosts et utiliser la ligne cmd svn.

Vous pouvez éviter d'indexer Xcode. Cela améliorera les performances de la mémoire de votre système mais empêchera également les fonctionnalités IDE telles que la saisie semi-automatique et le passage aux définitions de fonctionner.

$ defaults write com.apple.dt.XCode IDEIndexDisable 1

Si vous avez des performances lentes lors de la modification d'un fichier .xib avec le générateur / éditeur d'interface, allez sous Inspecteur de fichiers pour le .xib et désactivez la mise en page automatique . Apportez vos modifications au .xib, puis comme étape finale, réactivez la mise en page automatique et ajoutez ou ajustez les contraintes.

J'ai finalement fait fonctionner mon Xcode normalement en désactivant la fonction git.

J'ai résolu mon problème en désactivant les instantanés comme décrit ici:

La modification du storyboard dans Xcode 5 est très lente

Dans mon cas, c'était l'utilisation de la RAM.

Essayez de supprimer quelques onglets Chrome ou des applications rarement utilisées.

J'ai trouvé une astuce pour accélérer les performances de compilation de XCode 4: lorsque vous exécutez, compilez ou effectuez tout autre traitement dans Xcode et qu'il bloque le moniteur actif ouvert, sélectionnez le processus Xcode, puis cliquez sur l'exemple de processus. Cela va décoller le processus et le redémarrer normalement, ce qui permet de créer une application dans un délai raisonnable.