Pourquoi le temps de compilation de Swift est-il si lent?

il s'est avéré que Rob Napier avait raison. C'était un seul fichier (en fait une seule méthode) qui faisait que le compilateur devenait berzek.

ne vous méprenez pas. Swift recompile tous vos fichiers à chaque fois, mais la grande chose maintenant, C'est que Apple a ajouté le feedback de compilation en temps réel sur les fichiers qu'il compile, donc Xcode 6 GM montre maintenant quels fichiers Swift sont compilés et l'état de la compilation en temps réel comme vous pouvez le voir dans cette capture d'écran:

donc c'est très pratique pour savoir lequel de vos fichiers est si long. 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 le bien title était de type var title:String? et non NSString . Le compilateur devenait fou en l'ajoutant au NSMutableDictionary .

Changer l':

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : NSString(string: self.title ?? "")
        ])

return dic.copy() as NSDictionary

a fait passer la compilation de 10/15 secondes (peut-être même plus) à une seule seconde... étonner.

nous avons essayé pas mal de choses pour combattre cela car nous avons environ 100k lignes de Code Swift et 300k lignes de code ObjC.

notre première étape a été d'optimiser toutes les fonctions en fonction de la fonction compiler les sorties de temps (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 il a apporté notre temps de compilation de 5-6min à ~1minute.

ceci est maintenant défunte parce que nous avons demandé à Apple à ce sujet et ils nous ont conseillé de faire ce qui suit:

1. activez" l'optimisation du module entier "dans le paramètre de construction" Swift Compiler - génération de Code". Sélectionnez 'Fast, Whole Module Optimization'

2. Dans "Compilateur Swift-Drapeaux Personnalisés", pour vos constructions de développement, ajouter '-Onone'

lorsque ces options sont activées, le compilateur compilera tous les fichiers Swift en une seule étape. Nous avons trouvé avec notre script de fusion que c'est beaucoup plus rapide que de compiler des fichiers individuellement. Cependant, sans le ' -Onone' override, il optimisera également l'ensemble du module, qui est plus lent. Lorsque nous plaçons le drapeau '-Onone' dans les autres drapeaux Swift, cela arrête l'optimisation, mais cela n'arrête pas la compilation de tous les fichiers Swift en une seule étape.

pour plus d'informations sur l'optimisation de module entier, consultez le blog D'Apple post here - https://swift.org/blog/whole-module-optimizations /

nous avons trouvé que ces paramètres permettent à notre Code Swift de se compiler en 30 secondes : -) je n'ai aucune preuve de comment cela fonctionnerait sur d'autres projets, mais je suggérez de l'essayer si les temps de compilation Swift sont toujours un problème pour vous.

Note pour les constructions de votre App store, vous devez laisser le drapeau '-Onone' éteint, car l'optimisation est recommandée pour les constructions 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 qui vous permettra de compiler les temps fichier par fichier.

la chose à noter est que, par défaut, il construit 2 fichiers simultanément par chaque noyau CPU, et ne vous donnera pas le temps" net "écoulé, mais le temps" utilisateur " absolu. De cette façon, tous les temps s'équilibrent entre les fichiers parallélisés et similaire.

pour surmonter cela, a placé le drapeau -jobs à 1 , de sorte qu'il ne parallélise pas les constructions de fichier. Cela prendra plus de temps, mais à la fin vous aurez "net" compiler les temps que vous pouvez comparer dossier par dossier.

C'est un exemple de commande qui devrait faire l'affaire:

xctool -workspace <your_workspace> -scheme <your_scheme> -jobs 1 build

la sortie de la phase "compiler des fichiers Swift" serait quelque chose comme:

...
   ✓ Compile EntityObserver.swift (1623 ms)
   ✓ Compile Session.swift (1526 ms)
   ✓ Compile SearchComposer.swift (1556 ms)
...

à partir de cette sortie, vous pouvez rapidement identifier les fichiers qui prennent plus de temps que d'autres à compiler. En outre, vous pouvez déterminer avec une grande précision si vos remaniements (moulages explicites, conseils de type, etc...) d'abaisser les temps de compilation pour des fichiers spécifiques ou non.

NOTE: techniquement, vous pouvez aussi le faire avec xcodebuild mais la sortie est incroyablement verbeuse et difficile à consommer.

cela a probablement peu à voir avec la taille de votre projet. C'est probablement un morceau de code spécifique, peut-être même juste une ligne. Vous pouvez tester cela en essayant de compiler un fichier à la fois, plutôt que de l'ensemble du projet. Ou essayez de regarder les journaux de compilation pour voir quel fichier est si long.

comme exemple des types de code qui peuvent causer des problèmes, ce gist de 38 lignes prend plus d'une minute pour compiler dans beta7. Tout cela est causé par ce bloc:

let pipeResult =
seq |> filter~~ { "151900920" % 2 == 0 }
  |> sorted~~ {  < "151900920" }
  |> map~~ { "151900920".description }
  |> joinedWithCommas

Simplifier que par juste une ligne ou deux et il compile presque instantanément. Le problème est que cela provoque une croissance exponentielle (peut-être une croissance factorielle) dans le compilateur. Évidemment, ce n'est pas idéal, et si vous pouvez isoler de telles situations, vous devriez ouvrir les radars pour aider à obtenir ces problèmes nettoyés.

dans mon cas, Xcode 7 n'a fait aucune différence. J'avais 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 déballage des optionnels, le temps de construction a chuté 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 ce post et ce post .

Moment de la construction de l'Analyseur pour Xcode

i a développé un plug-in Xcode qui peut être utile pour quiconque connaît ces problèmes.

il semble y avoir des améliorations dans Swift 3, donc nous espérons que notre Code Swift sera compilé plus rapidement.

la solution est le moulage.

j'avais toute une série 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 que j'ai rencontré concernant les types de données que j'ai codé dur dans mon application.

une chose à noter est que le moteur D'inférence de type Swift peut être très lent avec les types imbriqués. Vous pouvez obtenir une idée générale de ce qui cause la lenteur en regardant le journal de compilation pour les unités de compilation individuelles qui prennent beaucoup de temps, puis en copiant et en collant la commande complète Xcode-spawned dans une fenêtre de Terminal, puis en tapant CTRL-\ pour obtenir quelques diagnostics. Regardez http://blog.impathic.com/post/99647568844/debugging-slow-swift-compile-times pour un exemple complet.

nous ne pouvons probablement pas corriger le compilateur Swift, mais quelque chose que nous pouvons corriger est notre code!

il y a une option cachée dans le compilateur Swift qui imprime les intervalles de temps exacts que prend le compilateur pour compiler 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.

simple exécuter ce qui suit dans le terminal et analyser 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

génial Brian Irace a écrit un article brillant à ce sujet Profiling your Swift compilation times .

assurez-vous également que lors de la compilation pour le débogage (soit Swift, soit Objective-C), vous définissez uniquement L'Architecture Active:

puisque tout cela est en Beta, et que le compilateur Swift n'est pas (du moins à partir d'aujourd'hui) ouvert, je suppose qu'il n'y a pas de réponse réelle à votre question.

tout d'abord, comparer Objective-C à Swift compilateur est en quelque sorte cruel. Swift est toujours en version bêta, et je suis sûr Qu'Apple travaille à fournir des fonctionnalités et à corriger les bogues, plus que fournir la vitesse de la foudre (vous ne commencez pas à construire une maison en achetant le mobilier). Je suppose Qu'Apple va optimiser le compilateur dans les temps.

si pour une raison quelconque tous les fichiers source doivent être compilés complètement, une option pourrait être de créer des modules/bibliothèques séparés. Mais cette option n'est pas encore possible, car Swift ne peut pas autoriser les bibliothèques tant que la langue n'est pas stable.

j'imagine 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 pourrait bien que le compilateur ait besoin de tout compiler à partir de zéro. Mais une fois que l' la langue atteint une version stable et le format des binaires ne change plus, nous serons en mesure de créer nos bibliothèques, et peut-être (?) le compilateur pourra également optimiser son travail.

je suppose, cependant, que seule Apple le sait...

pour Xcode 8, allez dans Paramètres du projet, puis Editor > Add Build Setting > Add User-Defined Setting, et ajoutez ce qui suit:

SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

ajouter ce drapeau a fait tomber nos temps de compilation clean-build de 7 minutes à 65s pour un projet swift 40KLOC, miraculeusement. Peut également confirmer 2 amis ont vu des améliorations similaires sur les projets d'entreprise.

Je ne peux que supposer qu'il s'agit d'une sorte de bogue dans Xcode 8.0

EDIT: It ne semble pas fonctionner dans Xcode 8.3 pour certaines personnes.

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 Swift:

• la Scission de l'application dans les Cadres de réduire la recompilation de l'impact. Mais soyez conscient que vous devez éviter les dépendances cycliques dans votre application. Pour plus d'informations sur ce sujet, consultez ce post: 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 zones où vous devez changer très souvent ou les zones qui nécessitent beaucoup d'itérations de compilation/exécution pour être complètes (presque toutes les choses liées à L'UI), mieux utiliser L'Objectif-C avec une approche de mix-and-match.

• Essayez d'exécution d'injection de code avec 'Injection pour Xcode'

• utiliser la méthode roopc: http://roopc.net/posts/2014/speeding-up-swift-builds/

• soulage le moteur d'inférence de type swift en donnant quelques conseils avec des moulages explicites.

tableaux et dictionnaires Swift construction semblent être une cause assez populaire pour cela (spécialement pour vous qui venez d'un Ruby arrière-plan), c'est-à-dire,

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 le fixer:

var a = NSMutableDictionary()
a["a"] = "b"
a["c"] = "d"
... and so on

pour déboguer et tester, assurez-vous d'utiliser les paramètres suivants pour réduire le temps de compilation d'environ 20 minutes à moins de 2 minutes,

1. dans project build settings, rechercher " optimisation" Tournez le débogage vers "le plus rapide [- O3]" ou au-dessus.
2. Ensemble pour Construire Active de l'Architecture: OUI
3. les informations de Débogage format: NAIN
4. optimisation du Module entier: NO

j'ai perdu d'innombrables heures à attendre que le projet de construire seulement pour réaliser que j'ai dû faire un petit changement et ai dû attendre un autre entier 30 minutes pour le tester. Ce sont les réglages qui ont fonctionné pour moi. (Je suis toujours à expérimenter avec les paramètres)

mais, assurez-vous que vous mettez au moins "nain avec dSYM" (si vous voulez surveiller votre application) et construire L'Architecture Active À "non" pour la libération/archivage pour pousser à iTunes Connect (je me souviens avoir gaspillé un quelques heures ici aussi).

le redémarrage de mon Mac a fait des merveilles pour ce numéro. Je suis passé de 15 minutes à 30 secondes juste en redémarrant.

le compilateur passe beaucoup de temps à inférer et à vérifier les types. Ainsi, l'ajout d'annotations de type aide du compilateur beaucoup.

si vous avez beaucoup d'appels de fonction enchaînés comme

let sum = [1,2,3].map({String("151900920")}).flatMap({Float("151900920")}).reduce(0, combine: +)

puis le compilateur prend un certain temps pour comprendre ce que le type de sum devrait être. Ajouter le type aide. Ce qui aide aussi est de tirer les étapes intermittentes dans des variables séparées.

let numbers: [Int] = [1,2,3]
let strings: [String] = sum.map({String("151910920")})
let floats: [Float] = strings.flatMap({Float("151910920")})
let sum: Float = floats.reduce(0, combine: +)

Spécialement pour les types numériques CGFloat , Int il peut aider beaucoup. Un nombre littéral comme 2 peut représenter de nombreux types numériques différents. Le compilateur doit donc comprendre à partir du contexte ce qu'il est.

des Fonctions qui prennent beaucoup de temps à regarder comme + , doit être évitée. Utiliser plusieurs + pour concaténer plusieurs tableaux est lent parce que le compilateur a besoin de comprendre quelle implémentation de + devrait être appelé pour chaque + . Ainsi, utilisez un var a: [Foo] avec append() à la place si possible.

vous pouvez ajouter un avertissement pour détecter les fonctions qui sont lentes à compiler dans le Xcode .

dans paramètres de construction pour votre recherche de cible pour autres drapeaux Swift et ajouter

-Xfrontend -warn-long-function-bodies=100

pour prévenir pour chaque fonction que il faut plus de 100 ms pour compiler.

pour les projets qui combinent Objectif-C et Code Swift, nous pouvons définir -enable-bridging-pch dans Other Swift Flags . Avec cela, l'en-tête passerelle n'est analysée qu'une seule fois, et le résultat (un "en-tête précompilé" ou un fichier "PCH" temporaire) est mis en cache et réutilisé dans tous les fichiers Swift de la cible. Apple a déclaré qu'il réduit le temps de construction de 30%. Lien De Référence:

NOTE: cela ne fonctionne que pour Swift 3.1 et au-dessus.

Swift compile time a été amélioré dans le nouveau Xcode 6.3

améliorations des compilateurs

le compilateur Swift 1.2 a été conçu pour être plus stable et améliorer la performance dans tous les sens. Ces changements offrent également une expérience de travail avec Swift dans Xcode. Certains des plus visibles les améliorations comprennent:

Incremental construit

les fichiers Source qui n'ont pas changé ne seront plus compilés par par défaut, ce qui améliorera considérablement les temps de construction pour la plupart des cas. Des changements structuraux plus importants de votre code peuvent encore exiger plusieurs fichiers à reconstruire.

exécutables plus rapides

debug construit des binaires produits qui tournent beaucoup plus vite, et de nouveaux optimisations offrir encore mieux Libérer la performance de construction.

Mieux compilateur diagnostics

des messages D'erreur et d'avertissement plus clairs, ainsi que de nouveaux Fix-its, le rendent plus facile d'écrire le bon Code Swift 1.2.

améliorations de la Stabilité

les accidents de compilateurs les plus courants ont été corrigés. Vous devriez aussi voir moins d'Avertissements SourceKit dans L'éditeur Xcode.

voici un autre cas qui peut causer des ralentissements massifs avec une inférence de type. Coalescence des opérateurs .

changement de ligne comme:

abs(some_optional_variable ?? 0)

à

abs((some_optional_variable ?? 0) as VARIABLE_TYPE)

a aidé à porter mon temps de compilation de 70s à 13s

rien ne fonctionnait pour moi dans Xcode 6.3.1 - quand j'ai ajouté environ 100 fichiers Swift Xcode accroché au hasard sur la construction 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 été travail comme de la magie pour moi - accélérer Swift Compilation . Il a réduit le temps de compilation à 3 minutes de 10 minutes.

il est dit que vous devez allumer le Whole Module Optimization tout en ajoutant -Onone Other Swift Flags .

j'utilise Swift 3 Xcode 8.3 / Xcode 8.2 .