Xcode 4 - performance lente
J'ai un problème avec Xcode 4 qui réagit très lentement aux interactions de l'utilisateur, par exemple. édition de code, zones de défilement, etc. Cela se produit notamment avec des projets de grande envergure comportant de nombreux contrôleurs/fichiers de visualisation, etc.
J'ai complètement nettoyé le disque dur et réinstallé Snow Leopard et Xcode la semaine dernière, mais le temps de réponse a été frustrant, ce qui a de nouveau perturbé (sur plusieurs jours) 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 si je peux faire quelque chose pour améliorer les performances, à part obtenir une machine plus performante en premier lieu.
Pour info, j'utilise MacBook avec des processeurs Intel Core 2 Duo à 2 GHz et 4 Go de RAM.
Au cas où nous devions effectuer une mise à niveau, j'aimerais également savoir si les performances de Xcode 4 sur les machines bien spécifiées sont médiocres (ce qui rendrait notre mise à niveau matérielle plutôt inutile, car seul le code Xcode présente un problème de performances sur le MacBook).
Si quelqu'un a des suggestions ou des recommandations ou peut 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 constituerait également une ressource précieuse pour d'autres développeurs occupant un poste similaire.
Si vous purgez le fichier d'espace de travail, cela accélère le processus.
Tout d'abord, assurez-vous que Xcode n'est pas ouvert. Maintenant, trouvez 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 cela pouvait poser problème pour certains projets. Assurez-vous de disposer d'une copie de sauvegarde de votre projet avant d'exécuter ces étapes et n'oubliez pas de vérifier et de tester votre projet par la suite . Assurez-vous de toujours avoir tous vos exécutables et schémas.
MISE À JOUR IMPORTANTE: Les chemins d'accès ont été modifiés pour Xcode 6 (Merci pour le commentaire dcc)! Je viens d'ajouter la voie alternative.
Il existe une autre astuce intéressante pour accélérer la construction en créant un disque virtuel 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 faites attention, vous devez avoir assez de mémoire. Bien entendu, vous pouvez créer une image plus petite, comme 2 Go (4237927).
Ensuite, vous dites à Xcode d’y stocker les données dérivées 
Vous ne pouvez pas dire à Xcode de stocker directement les données du simulateur iPhone, mais vous pouvez créer un dossier sur le disque mémoire et créer un lien symbolique à la place 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 virtuel disparaîtra au redémarrage de votre ordinateur. Il peut donc être judicieux de créer un script ou quelque chose qui s'exécute au démarrage. ET NE PLACEZ AUCUNE DONNEE QUE VOUS VOULEZ CONSERVER !!!
MISE À JOUR 2013-03-12:
Lisez le commentaire de Francisco Garcia ci-dessous!
Avec mon nouveau MBP (contenant un lecteur SSD), je n’ai plus besoin de cette méthode. Xcode fonctionne comme l'enfer :). J'espère que cela n'est pas perçu comme une publicité pour le grand souci des fruits, 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 eu un impact décisif. J'ai également mis en place un schéma sans gdb activé pour les situations dans lesquelles je suis souvent en train de recommencer (aucune accélération de lancement de gdb n'est assez forte).
Xcode 4.2, 4.3:
Problèmes majeurs liés à l'indexeur de fichiers (même code que celui qui exécute Spotlight, qui est défectueux depuis des années? Probablement).
Désactivez tout ce qui est non essentiel à la "surveillance" de fichiers:
- Aide rapide (NB: ne jamais cliquer sur l’onglet QH! Même cacher l’assistant provoque toujours l’exécution du code! Basculez vers un onglet différent avant de passer à un nouveau fichier ...)
- Gestion SCM (SVN, Git, etc. - Le support de git de Xcode est toujours un peu buggé (des projets corrompus), et ils ont abandonné le support de SVN, vous ne devriez donc pas l'utiliser de toute façon!)
- essayez de supprimer votre dossier d’espace de travail (selon la réponse acceptée), mais uniquement si sa taille est importante sur le disque.
- ... tout ce que vous pouvez trouver concernant l'état des fichiers individuels
Xcode 4.4, 4.5:
Ces versions ont une fuite de mémoire majeure, un indexeur de fichier cassé (mais meilleur que les versions 4.2 et 4.3) et peut-être un problème de fichier d'échange privé.
Finalement, en désactivant/activant l’espace de swap ( comment désactiver ou activer l’échange dans mac os x ), en utilisant des disques durs normaux sur plusieurs machines, et en exécutant des expériences sur des machines de 2 Go RAM jusqu’à 16 Go de RAM, j’ai constaté que Xcode semblait disposer de son propre espace de swap, indépendant de celui d’OS X (!).
(Cela pourrait être une erreur - il existe peut-être une forme supplémentaire d'échange avec OS X que je ne connais pas - mais les fichiers d'échange système ne sont pas devenus plus gros ou plus petits, alors que l'espace disque augmentait de quelques giga-octets sur certaines machines)
Observé:
Xcode 4.4/4.5 prendra au hasard tous les RAM de votre système (10 Go de projet pour un projet minuscule)), de sorte que le reste du système s'arrête, en attente de l'échange de disque.
- Pire: sur les macbooks avec SSD, vous ne saurez pas que c'est arrivé
- WORST: ... même s'il est possible que votre disque dur soit endommagé (les disques SSD n'aiment pas les écritures écrasantes)
Xcode accédera au disque dur afin qu’il puisse faire son indexation (cassée) de fichier interne. Lorsque la mémoire système devient insuffisante et que OS X doit procéder à un échange ... il est bloqué dans l'attente de l'indexation des fichiers par Xcode ... et Xcode utilise davantage de mémoire en attendant ... et: BOOM! sur des systèmes plus petits, OS X se bloque finalement
Xcode n'a pas besoin d'espace d'échange OS X
Le dernier est très intéressant. Si vous avez beaucoup de mémoire (par exemple, 16 Go), essayez de désactiver de manière permanente l’espace de permutation. Xcode s'exécute plus rapidement, car OS X Lion a quelques bugs dans la gestion de la mémoire où il échange même lorsqu'il n'est pas nécessaire de le faire .
Si xcode ralentit brusquement, il effectue une permutation interne, auquel cas vous pouvez simplement le tuer et le redémarrer.
(Si vous avez un disque SSD, le seul moyen de savoir si le swap a commencé est d’attendre qu’il ralentisse. Sinon, vous savez dès que vous entendez le thrash HD: il n’ya plus de fichier d'échange système, de sorte que la seule cause possible est Xcode)
Vous pouvez désactiver le swap en toute sécurité même si vous avez 2 Go RAM (un seul plantage OS X par mois lorsque j'ai essayé cela, l'a exécuté de cette façon pendant un an), mais cela vous empêchera de le faire. les vidéos/graphismes haut de gamme fonctionnent avec des fichiers nécessitant plusieurs gigaoctets juste pour être exécutés. N'hésitez pas à l'essayer pendant quelques semaines pour voir ce qui se passe.
Mais ... redémarrer Xcode à chaque ralentissement fonctionne à merveille. Sur les ordinateurs avec moins de RAM, le fichier d'échange privé de Xcode semble être immédiatement supprimé lorsque vous fermez l'ordinateur (cela ne semble pas se produire sur des ordinateurs avec beaucoup de RAM)
Je ne sais pas si cela aide quelqu'un, mais pour moi, XCode a considérablement augmenté ses performances après l'avoir configuré pour qu'il s'exécute en mode 32 bits (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 de la souris sur l'application (dans / Developer/Applications/XCode.app) et en sélectionnant Obtenir des informations. = et vérifiant Ouvert en mode 32 bits.
Aucune de ces réponses n'a vraiment amélioré les performances dans mon cas (au fil du temps, Xcode 4.1 est devenu difficilement utilisable, seulement en le quittant de temps en temps, cela a aidé).
Cependant, je viens de découvrir que si je continue à fermer tous mes documents (contrôle-commande-W), il semble rester rapide. Xcode conserve automatiquement tous les documents sur lesquels vous cliquez en mémoire et vous pouvez les naviguer avec la flèche gauche/droite de contrôle-commande. Si vous en ouvrez trop par inadvertance (notamment les fenêtres IB), l’arrêt s’arrête. Le fait de fermer tous les documents ouverts de temps en temps semble atténuer le problème sans qu'il soit nécessaire de redémarrer complètement.
Le billet suivant de @lukasz a un peu aidé, en particulier son élément n ° 8 dans sa réponse (panneau des utilitaires fermés et volet d'aide rapide).
Toute personne rencontrant ces problèmes devrait essayer Xcode 4.1 sur Mac OS X Lion. Je suis surpris de voir comment beaucoup plus rapide et réactif, il est 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 problèmes de performances avec cette version.
Lancez Instruments avec le modèle de profil horaire et attachez-le au Xcode en cours d’exécution (ou clang, llvm, etc. si votre problème survient lors de la construction). Vous devriez être capable 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 depuis la version bêta mais sont toujours persistants. Il semble que Xcode ait en interne une (ou plusieurs ...) fuites qui flottent dans votre mémoire, vous pouvez très bien observer cette "fonctionnalité" astucieuse lorsque vous utilisez l'Interface-Builder intégré. Deux solutions possibles sous Prier et remplir des rapports de bugs à Apple:
- N'utilisez pas de générateur interne, lancez plutôt l'application externe
- Quittez Xcode de temps en temps, cela devrait libérer la mémoire qui a été perdue
Désolé, mais je pense qu'il n'y a pas de meilleures solutions ....: /
J'ai finalement obtenu mon travail normal en désactivant la fonction git.
J'ai trouvé un truc pour accélérer les performances de compilation de XCode 4:
Lorsque vous exécutez, compilez ou effectuez tout autre traitement dans xcode et que vous bloquez le moniteur actif, sélectionnez Processus xcode, puis cliquez sur Exemple de processus. Le processus se déroulera normalement, ce qui permettra de créer une application dans un délai raisonnable. Au moins ça marche pour moi.
Volonté
J'ai essayé à peu près tout ce qui a été suggéré dans ce fil et dans de nombreux autres et la seule chose qui a fonctionné pour moi a été de "désactiver" Subversion pour le projet. Voici la partie la plus merdique - le SEUL moyen de "désactiver" le plug-in SVN intégré a été de figer mon fichier/etc/hosts avec une fausse adresse IP, ce qui a pour effet de faire échouer tous les accès SVN.
J'ai essayé de supprimer/renommer IDESubversion.ideplugin dans/Developer/Library/Xcode/PrivatePlugIns, mais Xcode 4.2.1 a été créé 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 se bloque après quelques minutes.
J'ai essayé d'éteindre "État à distance" via Fichier-> Contrôle de la source-> Masquer l'état à distance (rien n'a été 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 bascule d’un fichier à l’autre.
$ grep 1.2.3.4 /etc/hosts
1.2.3.4 svn.myhost.com
Ensuite, lorsque je veux vraiment faire du contrôle de version, je dois décompresser le fichier hosts et utiliser cmd line svn.
Dans mon cas, c’était l’utilisation de RAM.
Essayez de tuer quelques Chrome onglets, ou des applications rarement utilisées. Cela devrait aider!
Beaucoup de bonnes suggestions ici, j'ai résolu mon problème en désactivant les instantanés comme décrit ici:
Si vos performances sont lentes lors de la modification d'un fichier .xib avec le constructeur/éditeur d'interface, accédez à Inspecteur de fichiers pour .xib et désactivez la disposition automatique. Apportez vos modifications au fichier .xib, puis, comme dernière étape, réactivez la mise en page automatique et ajoutez ou ajustez des contraintes.
Vous pouvez éviter d'indexer Xcode. Cela améliorera les performances de la mémoire de votre système, mais empêchera également les IDE) fonctionnalités telles que l'auto-complétion et le saut aux définitions.
$ defaults write com.Apple.dt.XCode IDEIndexDisable 1