Xcode 4 - performances lentes

Question

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

J'ai complètement effacé le disque dur et réinstallé Snow Leopard et Xcode la semaine passée, mais peu à peu la réactivité s'est dégradée de nouveau de manière frustrante (sur plusieurs jours), perturbant considérablement le flux de travail.

J'ai également parfois supprimé les "données dérivées" du projet via l'Organiseur -> 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 information, j'utilise un MacBook avec des processeurs Intel Core 2 Duo à 2 GHz et 4 Go de RAM.

Au cas où nous devrions procéder à une mise à niveau, j'aimerais également savoir si d'autres personnes rencontrent ces performances médiocres de Xcode 4 sur des machines bien équipées (ce qui rendrait notre mise à niveau matérielle plutôt inutile puisque c'est seulement Xcode qui présente un problème de performances sur le MacBook).

Si quelqu'un a des suggestions ou des recommandations, ou même pourrait nous informer sur la manière dont l'amélioration du matériel influence les performances de Xcode sur des structures de projets plus importantes, cela serait extrêmement utile et constituerait également une ressource précieuse pour d'autres développeurs dans une situation similaire.

Answer 1

Si vous purifiez le fichier de l'espace de travail, cela aide à le rendre plus rapide.

Tout d'abord, assurez-vous que Xcode n'est pas ouvert. Trouvez maintenant votre fichier de projet. Cliquez dessus avec le bouton droit de la souris et sélectionnez Afficher le contenu du paquet.

Ensuite, supprimez project.xcworkspace.

Ouvrez Xcode et profitez de meilleures performances !

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

---

Édition : 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 toujours d'avoir tous vos exécutables et schémas.

Answer 2

IMPORTANT UPDATE: Les chemins ont changé pour Xcode 6 (Merci pour le commentaire dcc)! Je viens d'ajouter la méthode alternative.

---

Il existe une autre astuce pour accélérer 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 soyez prudent, vous devez avoir suffisamment de mémoire. Bien sûr, vous pouvez créer une image plus petite comme 2 Go (qui serait 4237927).

Ensuite, vous indiquez à Xcode de stocker les données dérivées là-bas

Vous ne pouvez pas indiquer à Xcode de stocker directement les données du simulateur d'iPhone là-bas, mais vous pouvez créer un dossier sur le ramdisk et créer un lien symbolique à la place du répertoire du simulateur d'iPhone en faisant ceci:

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

Avec cette configuration, si je construis pour le simulateur, c'est rapide et efficace :)

Sachez que le ramdisk disparaîtra lorsque vous redémarrerez votre machine, il pourrait donc être judicieux de créer un script ou quelque chose qui s'exécute au démarrage. ET NE PLACEZ PAS DE DONNÉES QUE VOUS SOUHAITEZ CONSERVER À CET ENDROIT!!!

MAJ 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 à la vitesse de l'éclair :). J'espère que cela ne sera pas considéré comme de la publicité pour le grand géant de la pomme, c'est juste un retour d'expérience...

Answer 3

Désactiver les problèmes en direct dans les Préférences générales a fait une différence certaine. J'ai également configuré un schéma sans gdb activé pour les situations où je relance fréquemment (pas de gdb accélère considérablement le démarrage).

Answer 4

Pour moi, Xcode a gagné une énorme augmentation de performance après l'avoir réglé pour fonctionner en mode 32 bits (il était par défaut à 64 bits). C'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 puis en cochant Ouvrir en mode 32 bits.

Answer 5

Xcode 4.2, 4.3:

Problèmes majeurs avec l'indexeur de fichiers (le même code que celui de Spotlight, qui est buggy depuis des années? Probablement).

Désactivez tout ce qui n'est pas essentiel et qui est impliqué dans la "surveillance" des fichiers:

1. Aide rapide (NB: ne cliquez jamais sur l'onglet QH! Même en cachant l'Assistant, le code continue de s'exécuter! Passez à un onglet différent avant de passer à un nouveau fichier ...)
2. Gestion du SCM (SVN, Git, etc - le support git de Xcode est encore un peu buggy (peut corrompre les projets), et ils ont abandonné le support SVN, donc vous ne devriez pas l'utiliser de toute façon!)
3. essayez de supprimer votre dossier de workspace (comme indiqué dans la réponse acceptée), mais uniquement s'il est volumineux sur le disque
4. ...tout ce que vous pouvez trouver en rapport avec l'état des fichiers individuels

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 swap privé.

Finalement, en désactivant / activant l'espace de swap (comment désactiver ou activer le swapping dans mac os x), et en utilisant des disques durs normaux sur plusieurs machines, et en réalisant des expériences sur des machines avec 2 Go de RAM jusqu'à 16 Go de RAM, j'ai découvert que Xcode semble exécuter sa propre espace de swap, indépendamment du swap de OS X (!).

(cela pourrait être une erreur - peut-être qu'il y a une forme supplémentaire de swapping de OS X que je ne connais pas - mais les fichiers de swap du système n'ont pas augmenté ou diminué, tandis que l'espace disque sautait de plusieurs gigaoctets sur certaines machines)

Observé:

1. Xcode 4.4/4.5 prendra aléatoirement toute la RAM de votre système (des dizaines de Go pour un petit projet) de sorte que le reste du système se bloque, bloqué en attente de swapping de disque

   1. PIRE: sur les macbooks avec SSD, vous ne saurez pas que cela s'est produit
   2. LE PIRE: ...même s'il endommage peut-être votre disque dur (les SSD n'aiment pas les écritures intensives)

2. Xcode monopolisera l'accès au disque dur pour pouvoir effectuer son indexation de fichiers (cassée) interne. Lorsque la mémoire du système devient faible et que OS X doit effectuer un swapping ... il reste bloqué en attente de Xcode pour indexer les fichiers ... et Xcode prend plus de mémoire pendant qu'il attend ... et: BOOM! sur les systèmes plus petits, OS X finit par se bloquer

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

Le dernier point est très intéressant. Si vous avez beaucoup de mémoire (par exemple 16 Go), essayez de désactiver définitivement l'espace de swap. Xcode fonctionne plus rapidement, car OS X Lion a des bugs dans la gestion de la mémoire où il effectue un swapping même quand ce n'est pas nécessaire.

Si xcode ralentit soudainement, il effectue un swapping interne, à ce moment-là vous pouvez simplement le fermer et le redémarrer.

(si vous avez un SSD, la seule façon de savoir s'il a commencé à swap est d'attendre qu'il "ralentisse". Sinon, vous le saurez dès que vous entendrez le grincement du disque dur: il n'y a plus de swapfile système, donc la seule cause possible est Xcode)

Vous pouvez désactiver en toute sécurité le swap même si vous avez 2 Go de RAM (j'avais seulement un crash OS X par mois quand j'ai essayé cela, je l'ai utilisé de cette façon pendant un an), mais cela vous empêchera de faire un travail vidéo / graphique de haute qualité avec des fichiers nécessitant plusieurs gigaoctets pour s'exécuter. N'hésitez pas à essayer pendant quelques semaines et voir ce qui se passe.

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