Pourquoi le temps de compilation de Swift est-il si lent?
J'utilise Xcode 6 Beta 6.
C'est quelque chose qui me dérange depuis un certain temps maintenant, mais il est à un point où il est à peine utilisable maintenant.
Mon projet commence à avoir une taille décente de 65 fichiers Swift et quelques fichiers pontés Objective-C (qui ne sont en réalité pas la cause du problème).
Il semble qu'une modification légère d'un fichier Swift (comme l'ajout d'un simple espace dans une classe à peine utilisée dans l'application) entraînera la recompilation de tous les fichiers Swift de la cible spécifiée.
Après une enquête plus approfondie, nous avons constaté que la phase CompileSwiftoù Xcode exécute la commande swiftcsur tous les fichiers Swift de votre cible représente environ 100% du temps du compilateur.
J'ai fait des recherches plus approfondies et si je ne garde que le délégué de l'application avec un contrôleur par défaut, la compilation est très rapide, mais comme j'ajoutais de plus en plus de fichiers de projet, le temps de compilation commençait à devenir vraiment lent.
Maintenant, avec seulement 65 fichiers sources, il faut environ 8/10 secondes pour compiler chaque fois. Pas très rapide .
Je n'ai vu aucun message parler de ce problème, sauf celui-ci , mais il s'agissait d'une ancienne version de Xcode 6. Je me demande donc si je suis le seul dans ce cas.
UPDATE
J'ai vérifié quelques projets Swift sur GitHub comme Alamofire , Euler et CryptoSwift , mais aucun d'entre eux n'avait assez de fichiers Swift pour pouvoir comparer. Le seul projet que j'ai trouvé qui commençait un avoir décent taille était SwiftHN , et même s'il ne disposait que d'une douzaine de fichiers sources, je pouvais toujours vérifier La même chose, un simple espace et l’ensemble du projet nécessitait une recompilation qui commençait à prendre un peu de temps (2/3 secondes).
Comparé au code Objective-C, où l’analyseur et la compilation sont en plein essor, Swift ne pourra jamais gérer de gros projets, mais dites-moi que je me trompe.
MISE À JOUR AVEC Xcode 6 Bêta 7
Toujours aucune amélioration. Cela commence à devenir ridicule. Avec le manque de #import dans Swift, je ne vois vraiment pas comment Apple parviendra à optimiser cela.
UPDATE avec Xcode 6.3 et Swift 1.2
Apple a ajouté constructions incrémentielles (et de nombreuses autres optimisations du compilateur). Vous devez migrer votre code vers Swift 1.2 pour bénéficier de ces avantages, mais Apple a ajouté un outil dans Xcode 6.3 pour vous aider:
CEPENDANT
Ne te réjouis pas trop vite comme je l'ai fait. Le résolveur de graphes qu'ils utilisent pour rendre la construction incrémentielle n'est pas encore très optimisé.
En effet d’abord, les modifications apportées à la signature de la fonction ne sont pas examinées. Par conséquent, si vous ajoutez un espace dans le bloc d’une méthode, tous les fichiers dépendant de cette classe seront recompilés.
Deuxièmement, il semble créer l'arborescence en fonction des fichiers recompilés, même si une modification ne les affecte pas. Par exemple, si vous déplacez ces trois classes dans des fichiers différents
class FileA: NSObject {
var foo:String?
}
class FileB: NSObject {
var bar:FileA?
}
class FileC: NSObject {
var baz:FileB?
}
Maintenant, si vous modifiez FileAname__, le compilateur marquera évidemment FileAà être recompilé. Il recompilera également FileB(ce qui serait correct compte tenu des modifications apportées à FileAname__), , mais aussi FileCcar FileBest recompilé, ce qui est assez mauvais. FileCn'utilise jamais FileAici.
J'espère donc qu'ils amélioreront ce solveur d'arbres de dépendance ... J'ai ouvert un radar avec cet exemple de code.
UPDATE avec Xcode 7 beta 5 et Swift 2.0
Hier, Apple a publié la version bêta 5 et à l'intérieur des notes de publication, nous avons pu voir:
Swift Language & Compiler • Constructions incrémentielles: la modification du corps d'une fonction ne devrait plus entraîner la reconstruction des fichiers dépendants. (15352929)
Je l'ai essayé et je dois dire que cela fonctionne vraiment (vraiment!) Bien maintenant. Ils ont grandement optimisé les versions incrémentielles de Swift.
Je vous recommande vivement de créer une branche Swift2.0 et de conserver votre code à jour à l'aide de XCode 7 bêta 5. Vous serez ravi des améliorations apportées par le compilateur (cependant, je dirais que l'état global de XCode 7 est toujours lent et buggé)
UPDATE avec Xcode 8.2
Cela fait un moment que ma dernière mise à jour sur cette question est la, alors la voici.
Notre application contient maintenant environ 20 000 lignes de code presque exclusivement Swift, ce qui est correct mais pas exceptionnel. Il a subi la migration Swift 2 et que Swift 3. Il faut environ 5/6m pour compiler sur un Macbook pro mi-2014 (Intel Core i7 à 2,5 GHz), ce qui est normal pour une version propre.
Cependant, la construction incrémentale est toujours une blague malgré Apple affirmant que:
Xcode ne reconstruira pas une cible entière lorsque seules de petites modifications ont eu lieu. (28892475)
Évidemment, je pense que beaucoup d’entre nous ont ri après avoir vérifié cette absurdité (ajouter une propriété privée (privée!) À un fichier de mon projet recompilera le tout ...)
Je tiens à vous signaler les gars à ce fil sur les forums de développeurs Apple qui a quelques informations supplémentaires sur le problème (ainsi que apprécié la communication de dev Apple sur la question de temps en temps)
Essentiellement, les utilisateurs ont proposé quelques solutions pour améliorer la construction incrémentielle:
- Ajoutez un paramètre de projet
HEADER_MAP_USES_VFSdéfini àtruename__ - Désactiver
Find implicit dependenciesde votre schéma - Créez un nouveau projet et déplacez votre hiérarchie de fichiers vers le nouveau.
Je vais essayer la solution 3 mais la solution 1/2 n'a pas fonctionné pour nous.
Ce qui est paradoxalement drôle dans toute cette situation, c’est que lorsque nous avons atteint le premier post sur ce sujet, nous utilisions Xcode 6 avec du code Swift 1 ou Swift 1.1 lorsque nous avons atteint les premiers compilations lentes et maintenant environ deux ans plus tard, en dépit des améliorations effectives apportées par Apple the La situation est aussi grave qu’elle l’était avec Xcode 6. Quelle ironie.
En fait VRAIMENT regrette d'avoir choisi Swift plutôt que Obj/C pour notre projet en raison de la frustration quotidienne qu'il implique. (Je passe même à AppCode mais c'est une autre histoire)
Quoi qu'il en soit, je vois ce SO message qui a 32k + vues et 143 ups au moment d'écrire ces lignes, alors je suppose que je ne suis pas le seul. Accrochez-vous les gars, malgré le pessimisme sur cette situation, il pourrait y avoir une lumière au bout du tunnel.
Si vous avez le temps (et le courage!) Je suppose que Apple accueille les radars à ce sujet.
Jusqu'à la prochaine fois! À votre santé
UPDATE avec Xcode 9
Stumble on this aujourd'hui. Xcode a discrètement introduit un nouveau système de construction pour améliorer les terribles performances actuelles. Vous devez l'activer via les paramètres de l'espace de travail.
J'ai déjà essayé mais je mettrai à jour ce post une fois que ce sera fait. Cela semble prometteur cependant.
Eh bien, il s'est avéré que Rob Napier avait raison. C’est un fichier unique (en fait une méthode) qui a amené le compilateur à se connecter à Berzek.
Maintenant, ne vous méprenez pas. Swift recompile tous les fichiers à chaque fois, mais le grand avantage est qu'Apple a ajouté des commentaires de compilation en temps réel sur les fichiers qu'il compile. Xcode 6 GM indique désormais quels fichiers Swift sont compilés et l'état compilation en temps réel comme vous pouvez le voir sur cette capture d'écran:
Cela est donc très utile pour savoir lequel de vos fichiers prend si longtemps. Dans mon cas, c'était ce morceau de code:
var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
"url" : self.url?.absoluteString ?? "",
"title" : self.title ?? ""
])
return dic.copy() as NSDictionary
parce que la propriété title était de type var title:String? et non NSString. Le compilateur devenait fou en l'ajoutant à la NSMutableDictionary.
Le changer pour:
var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
"url" : self.url?.absoluteString ?? "",
"title" : NSString(string: self.title ?? "")
])
return dic.copy() as NSDictionary
fait que la compilation passe de 10/15 secondes (peut-être encore plus) à une seule seconde ... incroyable.
Nous avons essayé pas mal de choses pour y remédier, car nous avons environ 100 000 lignes de code Swift et 300 000 lignes de code ObjC.
Notre première étape consistait à optimiser toutes les fonctions en fonction de la sortie des temps de compilation de la fonction (par exemple, comme décrit ici https://thatthinginswift.com/debug-long-compile-times-Swift/ )
Ensuite, nous avons écrit un script pour fusionner tous les fichiers Swift en un seul fichier, ce qui casse les niveaux d’accès, mais notre temps de compilation est passé de 5-6 minutes à ~ 1 minute.
Cela a maintenant disparu, car nous avons interrogé Apple à ce sujet et ils nous ont conseillé de procéder comme suit:
- Activez «l'optimisation du module entier» dans le paramètre de construction «Compilateur Swift - Génération de code». Sélectionnez
'Fast, Whole Module Optimization'
- Dans 'Compilateur Swift - Indicateurs personnalisés', ajoutez
'-Onone'pour vos versions de développement.
Lorsque ces indicateurs sont définis, le compilateur compilera tous les fichiers Swift en une seule étape. Nous avons constaté avec notre script de fusion que cela est beaucoup plus rapide que la compilation de fichiers individuellement. Cependant, sans la substitution '-Onone', cela optimisera également tout le module, ce qui est plus lent. Lorsque nous définissons l'indicateur '-Onone' dans les autres indicateurs Swift, cela arrête l'optimisation, mais la compilation de tous les fichiers Swift ne s'arrête pas en une seule étape.
Pour plus d'informations sur l'optimisation de l'ensemble du module, consultez le blog d'Apple ici - https://Swift.org/blog/whole-module-optimizations/
Nous avons constaté que ces paramètres permettent à notre code Swift de compiler en 30 secondes :-) Je n'ai aucune preuve de son efficacité sur d'autres projets, mais je suggère d'essayer si les temps de compilation de Swift sont toujours un problème pour vous.
Remarque concernant les versions de votre App Store, vous devez laisser l'indicateur '-Onone' désactivé, car l'optimisation est recommandée pour les versions de production.
Si vous essayez d'identifier des fichiers spécifiques qui ralentissent votre temps de compilation, vous pouvez essayer de le compiler à partir de votre ligne de commande via xctool , ce qui vous donnera la compilation fichier par fichier.
La chose à noter est que, par défaut, il crée 2 fichiers simultanément pour chaque cœur de processeur, et ne vous donnera pas le temps écoulé "net", mais le temps "utilisateur" absolu. De cette façon, tous les délais sont égaux entre les fichiers parallélisés et se ressemblent beaucoup.
Pour résoudre ce problème, définissez l'indicateur -jobs sur 1 pour qu'il ne mette pas en parallèle les générations de fichiers. Cela prendra plus de temps, mais au final, vous aurez des temps de compilation "nets" pour comparer fichier par fichier.
Voici un exemple de commande qui devrait faire l'affaire:
xctool -workspace <your_workspace> -scheme <your_scheme> -jobs 1 build
La sortie de la phase "Compile Swift Files" devrait ressembler à ceci:
...
✓ Compile EntityObserver.Swift (1623 ms)
✓ Compile Session.Swift (1526 ms)
✓ Compile SearchComposer.Swift (1556 ms)
...
À partir de cette sortie, vous pouvez identifier rapidement les fichiers dont la compilation prend plus de temps que d’autres. De plus, vous pouvez déterminer avec une grande précision si vos refactorisations (transtypages explicites, indications de type, etc.) réduisent ou non les temps de compilation pour des fichiers spécifiques.
REMARQUE: techniquement, vous pouvez également le faire avec xcodebuild mais la sortie est incroyablement détaillée et difficile à utiliser.
Cela a probablement peu à voir avec la taille de votre projet. C'est probablement un morceau de code spécifique, peut-être même une seule ligne. Vous pouvez tester cela en essayant de compiler un fichier à la fois plutôt que le projet dans son ensemble. Ou essayez de regarder les journaux de construction pour voir quel fichier prend si longtemps.
Comme exemple des types de code pouvant causer des problèmes, ce Gist à 38 lignes prend plus d’une minute pour être compilé en version 7. Tout cela est causé par ce seul bloc:
let pipeResult =
seq |> filter~~ { $0 % 2 == 0 }
|> sorted~~ { $1 < $0 }
|> map~~ { $0.description }
|> joinedWithCommas
Simplifiez cela par une ligne ou deux et la compilation est quasi instantanée. Le problème est que quelque chose à ce sujet provoque une croissance exponentielle (éventuellement une croissance factorielle) du compilateur. Évidemment, ce n'est pas idéal, et si vous pouvez isoler de telles situations, vous devez ouvrir des radars pour aider à résoudre ces problèmes.
Dans mon cas, Xcode 7 n'a fait aucune différence. J'ai eu plusieurs fonctions nécessitant plusieurs secondes pour compiler.
Exemple
// Build time: 5238.3ms
return CGSize(width: size.width + (rightView?.bounds.width ?? 0) + (leftView?.bounds.width ?? 0) + 22, height: bounds.height)
Après avoir décompressé les options, la durée de construction a été réduite de 99,4%.
// Build time: 32.4ms
var padding: CGFloat = 22
if let rightView = rightView {
padding += rightView.bounds.width
}
if let leftView = leftView {
padding += leftView.bounds.width
}
return CGSizeMake(size.width + padding, bounds.height)
Voir plus d'exemples dans cet article et cet article .
Build Time Analyzer pour Xcode
J'ai développé un plug-in Xcode qui pourrait s'avérer utile pour les personnes confrontées à ces problèmes.
Il semble y avoir des améliorations à venir dans Swift 3, donc nous espérons que notre code Swift sera compilé plus rapidement à ce moment-là.
La solution est le casting.
J'ai eu un grand nombre de tonnes de dictionnaires, comme ceci:
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
.....
Il a fallu environ 40 minutes pour le compiler. Jusqu'à ce que je lance les dictionnaires comme ceci:
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
....
Cela a fonctionné pour presque tous les autres problèmes rencontrés concernant les types de données que j'ai codés en dur dans mon application.
Une chose à noter est que le moteur d'inférence de type Swift peut être très lent avec des types imbriqués. Vous pouvez avoir une idée générale de ce qui cause la lenteur en consultant le journal de construction pour connaître les unités de compilation individuelles qui prennent beaucoup de temps, puis en copiant et collant la commande Xcode générée dans une fenêtre de terminal, puis en appuyant sur CTRL-\pour obtenir des diagnostics. Jetez un coup d'oeil à http://blog.impathic.com/post/99647568844/debugging-slow-Swift-compile-times pour un exemple complet.
Nous ne pourrons probablement pas réparer le compilateur Swift, mais nous pouvons réparer notre code!
Il existe une option cachée dans le compilateur Swift qui affiche les intervalles de temps exacts nécessaires à la compilation de chaque fonction: -Xfrontend -debug-time-function-bodies. Cela nous permet de trouver des goulots d'étranglement dans notre code et d'améliorer considérablement le temps de compilation.
Exécutez simplement les opérations suivantes dans le terminal et analysez les résultats:
xcodebuild -workspace App.xcworkspace -scheme App clean build OTHER_Swift_FLAGS="-Xfrontend -debug-time-function-bodies" | grep [1-9].[0-9]ms | sort -nr > culprits.txt
Impressionnant Brian Irace a écrit un article brillant à ce sujet Profiler vos temps de compilation Swift .
Assurez-vous également que, lors de la compilation pour le débogage (Swift ou Objective-C), vous définissez l'option Construire une architecture active uniquement:
Puisque tout cela est en version bêta et que le compilateur Swift n’est pas ouvert (du moins à ce jour), je suppose qu’il n’ya pas de vraie réponse à votre question.
Tout d’abord, comparer le compilateur Objective-C à Swift est quelque peu cruel. Swift est toujours en version bêta, et je suis sûr que Apple s’efforce de fournir des fonctionnalités et de corriger les bugs, plus que de fournir une vitesse d’éclair (vous ne commencez pas à construire une maison en achetant les meubles). Je suppose que Apple optimisera le compilateur en temps voulu.
Si, pour une raison quelconque, tous les fichiers source doivent être complètement compilés, vous pouvez éventuellement créer des modules/bibliothèques séparés. Mais cette option n’est pas encore possible, car Swift ne peut autoriser les bibliothèques que si le langage est stable.
Je suppose qu'ils vont optimiser le compilateur. Pour la même raison que nous ne pouvons pas créer de modules pré-compilés, il se peut que le compilateur ait besoin de tout compiler à partir de zéro. Mais une fois que le langage atteindra une version stable et que le format des fichiers binaires ne changera plus, nous pourrons créer nos bibliothèques et peut-être que le compilateur pourra également optimiser son travail.
Juste deviner, cependant, car seul Apple sait ...
Pour Xcode 8, accédez aux paramètres du projet, puis à Editeur> Ajouter un paramètre de construction> Ajouter un paramètre défini par l'utilisateur, puis ajoutez les éléments suivants:
Swift_WHOLE_MODULE_OPTIMIZATION = YES
L'ajout de ce drapeau a fait chuter miraculeusement nos temps de compilation sans construction de 7 minutes à 65 secondes pour un projet 40KLOC Swift. Vous pouvez également confirmer que 2 amis ont constaté des améliorations similaires sur des projets d’entreprise.
Je ne peux que supposer que ceci est une sorte de bogue dans Xcode 8.0
EDIT: Cela ne semble plus fonctionner dans Xcode 8.3 pour certaines personnes.
Pour le débogage et les tests, veillez à utiliser les paramètres suivants pour réduire le temps de compilation d’environ 20 minutes à moins de 2 minutes.
- Dans les paramètres de construction du projet, recherchez "Optimisation" Réglez Debug sur "Le plus rapide [-O3]" ou une valeur supérieure.
- Définir la construction de l'architecture active: OUI
- Format des informations de débogage: DWARF
- Optimisation du module entier: NON
J'ai perdu d'innombrables heures à attendre la construction du projet, mais je me suis rendu compte que je devais faire ce petit changement et attendre 30 minutes supplémentaires pour le tester. Ce sont les paramètres qui ont fonctionné pour moi. (Je suis encore en train d'expérimenter avec les réglages)
Mais assurez-vous au moins que vous définissez "DWARF with dSYM" (si vous souhaitez surveiller votre application) et construisez Active Architecture sur "NO" pour la publication/archivage dans Push to iTunes Connect (je me souviens d'avoir perdu quelques heures ici aussi).
La construction de tableaux et de dictionnaires rapides semble être une cause assez populaire pour cela (spécialement pour vous qui venez de Ruby background),
var a = ["a": "b",
"c": "d",
"e": "f",
"g": "h",
"i": "j",
"k": "l",
"m": "n",
"o": "p",
"q": "r",
"s": "t",
"u": "v",
"x": "z"]
sera probablement la cause où cela devrait résoudre ce problème:
var a = NSMutableDictionary()
a["a"] = "b"
a["c"] = "d"
... and so on
Malheureusement, le compilateur Swift n’est toujours pas optimisé pour une compilation rapide et incrémentale (à partir de Xcode 6.3 beta). En attendant, vous pouvez utiliser certaines des techniques suivantes pour améliorer le temps de compilation de Swift:
Divisez l'application dans Frameworks pour réduire l'impact de la recompilation. Mais sachez que vous devez éviter les dépendances cycliques dans votre application. Pour plus d’informations sur ce sujet, consultez cet article: http://bits.citrusbyte.com/improving-Swift-compile-time/
Utilisez Swift pour les parties de votre projet qui sont assez stables et ne changent pas souvent. Pour les autres domaines dans lesquels vous devez changer très souvent ou ceux qui nécessitent de nombreuses itérations de compilation/exécution pour être complets (presque tous les éléments liés à l'interface utilisateur), mieux utiliser Objective-C avec une approche de combinaison.
Essayez l'injection de code d'exécution avec 'Injection for Xcode'
Utilisez la méthode roopc: http://roopc.net/posts/2014/speeding-up-Swift-builds/
Soulagez le moteur d'inférence de type Swift en donnant quelques astuces avec des conversions explicites.
Le compilateur passe beaucoup de temps à inférer et à vérifier les types. Donc, ajouter des annotations de type aide beaucoup le compilateur.
Si vous avez beaucoup d'appels de fonction chaînés comme
let sum = [1,2,3].map({String($0)}).flatMap({Float($0)}).reduce(0, combine: +)
Le compilateur met ensuite un certain temps à déterminer le type de sum. Ajouter le type aide. Ce qui aide également, c'est de tirer les étapes intermittentes dans des variables séparées.
let numbers: [Int] = [1,2,3]
let strings: [String] = sum.map({String($0)})
let floats: [Float] = strings.flatMap({Float($0)})
let sum: Float = floats.reduce(0, combine: +)
Surtout pour les types numériques CGFloat, Int cela peut aider beaucoup. Un nombre littéral tel que 2 peut représenter plusieurs types numériques. Le compilateur doit donc déterminer le contexte dans lequel il est.
Les fonctions qui prennent beaucoup de temps à rechercher comme + devraient également être évitées. L'utilisation de plusieurs + pour concaténer plusieurs tableaux est lente car le compilateur doit déterminer quelle implémentation de + doit être appelée pour chaque +. Donc, utilisez plutôt un var a: [Foo] avec append() si possible.
Vous pouvez ajouter un avertissement pour détecter les fonctions lentes à compiler dans Xcode .
Dans Build Settings pour votre recherche cible de Other Swift Flags et ajouter
-Xfrontend -warn-long-function-bodies=100
pour avertir pour chaque fonction dont la compilation prend plus de 100 ms.
Redémarrer mon Mac a fait des merveilles pour ce problème. Je suis passé de builds de 15 minutes à 30 secondes juste en redémarrant.
Pour les projets combinant les codes Objective-C et Swift, nous pouvons définir -enable-bridging-pch dans Other Swift Flags. Avec cela, l’en-tête de pontage n’est analysé qu’une seule fois et le résultat (un fichier temporaire «en-tête précompilé» ou «PCH») est mis en cache et réutilisé dans tous les fichiers Swift de la cible. Apple a affirmé qu'il réduisait le temps de fabrication de 30%. Lien de référence:
REMARQUE: Ceci ne fonctionne que pour Swift 3.1 et supérieur.
Le temps de compilation rapide a été amélioré dans le nouveau Xcode 6.3
Améliorations du compilateur
Le compilateur Swift 1.2 a été conçu pour être plus stable et améliorer la performance dans tous les sens. Ces changements fournissent également un meilleur expérience lorsque vous travaillez avec Swift dans Xcode. Certains des plus visibles les améliorations comprennent:
Constructions incrémentales
Les fichiers source qui n’ont pas changé ne seront plus recompilés par défaut, ce qui améliorera considérablement les temps de construction de la plupart des fichiers cas. Des modifications structurelles plus importantes de votre code peuvent encore nécessiter plusieurs fichiers à reconstruire.
Des exécutables plus rapides
Les versions de débogage produisent des fichiers binaires beaucoup plus rapides et de nouveaux fichiers les optimisations offrent des performances encore meilleures pour la version Release.
Meilleurs diagnostics du compilateur
Des messages d'erreur et d'avertissement plus clairs, ainsi que le nouveau correctif, en font un plus facile d’écrire le code Swift 1.2 approprié.
Amélioration de la stabilité
Les pannes les plus courantes du compilateur ont été corrigées. Vous devriez également voir moins d’avertissements SourceKit dans l’éditeur Xcode.
Voici un autre cas qui peut provoquer des ralentissements massifs avec l'inférence de type. Opérateurs de coalescence .
Changer de ligne comme:
abs(some_optional_variable ?? 0)
à
abs((some_optional_variable ?? 0) as VARIABLE_TYPE)
m'a permis d'amener mon temps de compilation de 70 à 13
Rien n’a fonctionné pour moi dans Xcode 6.3.1 - lorsque j’ai ajouté environ 100 fichiers Swift Xound accrochés au hasard à la compilation et/ou à l’indexation. J'ai essayé une option modulaire sans succès.
Installer et utiliser Xcode 6.4 Beta a réellement fonctionné pour moi.
Cela a fonctionné comme par magie pour moi - Accélérer la compilation rapide . Cela réduisait le temps de compilation à 10 minutes de 3 minutes à 3 minutes.
Il dit que vous devez activer le Whole Module Optimization tout en ajoutant -Onone dans Other Swift Flags.
J'utilise Swift 3 SUR Xcode 8.3/Xcode 8.2.