Xcode 4 – performance lente

J’ai un problème avec Xcode 4 qui réagit très lentement aux interactions des utilisateurs, par exemple le code d’édition, les zones de défilement, etc. Cela se produit en particulier avec les projets à 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 la semaine dernière, mais je suis revenu sur un temps de réponse frustrant (sur plusieurs jours), perturbant considérablement le stream de travail.

J’ai également à l’occasion supprimé les “données dérivées” du projet via l’organisateur -> Projets et cela a eu peu d’effet.

Je me demande s’il y a autre chose que je peux faire pour améliorer les performances, à part obtenir une machine plus sophistiquée en premier lieu.

Pour info, je lance MacBook avec des processeurs Intel Core 2 Duo à 2 GHz et 4 Go de RAM.

Au cas où nous aurions besoin de mettre à niveau, je voudrais également savoir si les gens rencontrent cette mauvaise performance de Xcode 4 sur des machines bien spécifiées (ce qui rendrait notre mise à niveau plutôt inutile car ce n’est que Xcode qui pose problème sur le MacBook).

Si quelqu’un a des suggestions ou des recommandations ou pourrait même nous faire savoir comment le matériel influe sur les performances de Xcode sur de plus grands arbres de projet, 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 d’espace de travail, cela accélère le processus.

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

entrer la description de l'image ici

Ensuite, supprimez project.xcworkspace .

entrer la description de l'image ici

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 causer 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 d’avoir 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’append la voie alternative.


Il existe une autre astuce intéressante pour fixer des 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 assez de mémoire. Bien sûr, vous pouvez créer une image plus petite comme 2 Go (ce serait 4237927).

Ensuite, vous indiquez à Xcode d’y stocker les données dérivées entrer la description de l'image ici

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 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 virtuel disparaîtra au redémarrage de 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 AUCUNE DONNEE QUE VOUS VOULEZ GARDER !!!

MISE À JOUR 2013-03-12:

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

  2. Avec mon nouveau MBP (contenant un lecteur 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 de la publicité pour le gros problème, c’est juste un rapport d’expérience …

La désactivation de Live Issues dans les préférences générales a fait une nette différence. J’ai également mis en place un schéma sans gdb activé pour les situations où je suis souvent en cours de réexécution (pas de gdb accélère pas assez le lancement).

Je ne sais pas si cela aide quelqu’un, mais pour moi, XCode a obtenu une énorme augmentation de performance après l’avoir configuré en mode 32 bits (il était de 64 par défaut). C’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 Lire les 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 est essentiel pour les fichiers “à regarder”:

  1. Aide rapide (NB: ne cliquez jamais sur l’onglet QH! Même cacher l’Assistant provoque toujours le lancement du code! Passez à un autre onglet avant de passer à un nouveau fichier …)
  2. La gestion SCM (SVN, Git, etc. – Le support git de Xcode est toujours un peu bogué (des projets peuvent corrompre), et ils ont abandonné le support SVN, vous ne devriez donc pas l’utiliser!)
  3. essayez de supprimer le dossier de votre espace de travail (selon la réponse acceptée), mais uniquement s’il est grand sur le disque
  4. … tout ce que vous pouvez trouver concernant le statut de chaque fichier

Xcode 4.4, 4.5:

Ces versions ont une fuite de mémoire majeure, un indexeur de fichiers cassé (mais meilleur 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 le swap dans Mac OS X ) et en utilisant des disques durs normaux sur plusieurs machines et en exécutant des expériences sur des machines de 2 Go de RAM jusqu’à 16 Go de RAM, semble exécuter son propre espace de swap, indépendamment du swap OS X (!).

(cela peut être une erreur – peut-être y a-t-il une forme supplémentaire de permutation d’OS X que je ne connais pas – mais les fichiers d’échange du système ne sont pas devenus plus volumineux, alors que l’espace disque a augmenté de quelques gigaoctets sur certaines machines)

Observé:

  1. Xcode 4.4 / 4.5 prend au hasard toute la mémoire vive de votre système (10 Go pour un tout petit projet) afin que le rest du système s’arrête, bloqué en attente d’échange de disque

    1. WORSE: sur les macbooks avec SSD, vous ne le saurez pas
    2. PIRE: … même si cela peut endommager votre disque dur (les disques SSD n’aiment pas les écritures)
  2. Xcode accédera au disque dur de manière à ce qu’il puisse effectuer son indexation de fichiers interne (cassée). Lorsque la mémoire système devient faible et que OS X a besoin de permuter, il rest bloqué à attendre que Xcode indexe les fichiers … et Xcode prend plus de mémoire pendant qu’il attend … et: BOOM! sur des systèmes plus petits, OS X finit par se bloquer

  3. 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 l’espace de swap de façon permanente. Xcode s’exécute plus rapidement, car OS X Lion a quelques bogues dans la gestion des mémoires, où il échange même s’il n’est pas nécessaire .

Si xcode ralentit brusquement, 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 soit plus lent. Sinon, vous savez dès que vous entendez le thrash HD: il n’y a plus de fichier d’échange système, donc seule cause possible est Xcode)

Vous pouvez désactiver en toute sécurité le swap même si vous avez 2 Go de RAM (je n’ai eu qu’un seul crash d’OS X par mois lorsque j’ai essayé, mais je l’ai fait pendant un an), mais cela vous empêchera de travailler avec des fichiers qui ont besoin de plusieurs gigaoctets juste pour fonctionner. N’hésitez pas à l’essayer pendant quelques semaines et à voir ce qui se passe.

Mais … le redémarrage de Xcode chaque fois qu’il ralentit fonctionne à merveille. 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 (au fil du temps, Xcode 4.1 est devenu difficilement utilisable, ne le quittant que de temps en temps).

Cependant, je viens de découvrir que si je continue à fermer tous mes documents (control-command-W), cela semble restr rapide. Xcode conserve automatiquement en mémoire tous les documents sur lesquels vous cliquez, et vous pouvez naviguer entre eux avec la flèche de commande gauche / droite. Si vous ouvrez accidentellement trop (en particulier les fenêtres IB), il s’arrête brutalement. Il suffit de fermer tous les documents ouverts maintenant et semble-t-il, mais cela ne nécessite pas de redémarrage complet.

Le post suivant par @lukasz a aidé un peu, en particulier son article n ° 8 dans sa réponse (Closed Utility Panel et Quick Help Pane)

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

Tous ceux qui rencontrent ces problèmes doivent essayer Xcode 4.1 sur Mac OS X Lion. Je suis surpris de voir combien il est 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 performance avec cette version.

Je suis confronté aux mêmes problèmes, ceux-ci ont été en partie corrigés depuis la version bêta mais sont toujours persistants. Il semble que Xcode en interne ait une (ou plusieurs …) fuites qui flottent dans votre mémoire, vous pouvez regarder cette astucieuse “fonctionnalité” lorsque vous utilisez l’interface intégrée. Deux solutions possibles sous la prière et le remplissage des rapports de bug à Apple:

  1. N’utilisez pas Builder interne, lancez plutôt l’application externe
  2. Quittez Xcode de temps en temps, cela devrait libérer la mémoire qui a été divulguée

Désolé, mais je pense qu’il n’y a pas de meilleures solutions ….: /

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 survient pendant les builds). 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.

J’ai essayé à peu près tout ce qui était suggéré dans ce sujet 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 la plus désagréable – la SEULE façon dont j’ai pu “désactiver” le plug-in SVN intégré était de friguer mon fichier / etc / hosts avec une adresse IP erronée, entraînant l’échec de tous les access SVN.

J’ai essayé de supprimer / renommer le fichier IDESubversion.ideplugin dans / Developer / Library / Xcode / PrivatePlugIns, mais Xcode 4.2.1 saute 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 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 ne montre pas le SBBOD presque chaque fois que je change de fichier.

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

Ensuite, quand je veux vraiment faire du contrôle de version, je dois dé-friguer le fichier hosts et utiliser cmd line svn.

J’ai trouvé une astuce pour accélérer les performances de compilation de XCode 4:

Lorsque vous exécutez ou comstackz ou effectuez un autre traitement dans xcode et que le moniteur actif est bloqué, sélectionnez le processus xcode, puis cliquez sur un exemple de processus. Cela rendra le processus décroché et fonctionnera de nouveau normalement, ce qui permettra de créer une application dans un délai raisonnable. Au moins cela fonctionne pour moi.

Volonté

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

entrer la description de l'image ici

Essayez de supprimer quelques tabs Chrome ou des applications rarement utilisées. Cela devrait aider!

J’ai finalement obtenu que mon xcode fonctionne normalement en désactivant la fonction git.

Beaucoup de bonnes suggestions ici, 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

Vous pouvez éviter l’indexation de Xcode. Cela permettra d’améliorer les performances de la mémoire de votre système, mais empêchera également les fonctionnalités de l’EDI, telles que l’autocomplétion, et d’accéder directement aux définitions.

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

Si vous avez des performances médiocres en modifiant un fichier .xib avec le générateur / éditeur d’interface, allez dans Inspecteur de fichiers pour le fichier .xib et désactivez la mise en page automatique . Apportez vos modifications au fichier .xib, puis, dans une dernière étape, réactivez la mise en page automatique et ajoutez ou ajustez les contraintes.