Xcode 6 mit super langsamer Eingabe und automatischer Vervollständigung von Swift

Ist es nur ich oder Xcode 6 (6.0.1) mit Swift scheint sehr langsam zu sein, wenn Sie Ihren Code eingeben, insbesondere bei automatischer Vervollständigung?

Eine normale Objective-C-Klasse funktioniert, selbst wenn sie sich in einem Swift-Projekt befindet, fast genauso wie zuvor. Es ist also Swift, der sie beendet.

Hat jemand die gleichen Unannehmlichkeiten? Haben Sie eine Idee, wie Sie die Leistung verbessern können?

• Ich habe versucht, mit einigen Einstellungen zu spielen, aber kein Glück.
• Ich habe natürlich auch versucht, Xcode und den Computer ohne Glück neu zu starten.
• Es sind keine anderen schweren Apps geöffnet.

Ich verwende ein Mid 2009 Macbook Pro (2,26 GHz Intel Core 2 Duo) mit 8 GB RAM und SSD HD, was überhaupt nicht das Neueste ist, aber immer noch kein kompletter Müll.

Es ist eine Schande, dass ich aufgeregt war, Swift zu verwenden, und es jetzt wirklich unerträglich ist.

Gedanken / Tipps?

• Beenden Sie Xcode und starten Sie den Mac neu. Dies ist nicht erforderlich, wird jedoch bevorzugt.
• Löschen Sie den Inhalt des Ordners ~ / Library / Developer / Xcode / DerivedData
• Löschen Sie den Inhalt ~ / Library / Caches / com.apple.dt.Xcode

Dies ist eine zeitliche Lösung, funktioniert aber sehr gut.

Unterhalb des Skripts mit der Skripteditor-App.

tell application "Terminal"
    do script "rm -frd ~/Library/Developer/Xcode/DerivedData/*"
    do script "rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
end tell

Alternativ können Sie einen Alias ​​für Ihr Terminal wie folgt erstellen:

alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* && rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"

Sie können dies zu Ihrem hinzufügen ~/.bash_profileund dann xcodecleanjedes Mal in die Befehlszeile eingeben, wenn Sie diese beiden Ordner löschen möchten.

Ich habe auch 100% + CPU erlebt, als ich einen "einfachen" Code eingegeben habe. Einige kleine Tricks, um den Swift-Parser durch die Strukturierung Ihres Codes zu beschleunigen.

Verwenden Sie den Concatinator "+" nicht in Zeichenfolgen. Für mich löst dies die Langsamkeit sehr schnell aus. Jedes neue "+" bringt den Parser zum Crawlen und muss den Code jedes Mal neu analysieren, wenn Sie irgendwo in Ihrem Funktionskörper ein neues Zeichen hinzufügen.

Anstatt:

var str = "This" + String(myArray.count) + " is " + String(someVar)

Verwenden Sie die Template-Syntax, die viel schneller zu analysieren scheint:

var str = "This \(myArray.count) is \(someVar)"

Auf diese Weise bemerke ich grundsätzlich keine Begrenzung in strlen mit Inline-Vars "\ (*)".

Wenn Sie Berechnungen haben, die + / * verwenden, teilen Sie diese in kleinere Teile auf.

Anstatt:

var result = pi * 2 * radius 

verwenden:

var result  = pi * 2
    result *= radius

Es mag weniger effizient aussehen, aber der schnelle Parser ist auf diese Weise viel schneller. Einige Formeln werden nicht kompiliert, wenn sie zu viele Operationen haben, selbst wenn sie mathematisch korrekt sind.

Wenn Sie einige komplexe Berechnungen haben, geben Sie diese in eine Funktion ein. Auf diese Weise kann der Parser es einmal analysieren und muss es nicht jedes Mal neu analysieren, wenn Sie etwas in Ihrem Funktionskörper ändern.

Denn wenn Sie eine Berechnung in Ihrem Funktionskörper haben, überprüft der schnelle Parser diese jedes Mal, ob die Typen, die Syntax usw. noch korrekt sind. Wenn sich eine Linie über der Berechnung ändert, haben sich möglicherweise einige Variablen in Ihrer Berechnung / Formel geändert. Wenn Sie es in eine externe Funktion einfügen, wird es einmal validiert und swift ist froh, dass es korrekt ist und es nicht ständig repariert, was die hohe CPU-Auslastung verursacht.

Auf diese Weise kam ich beim Tippen von 100% bei jedem Tastendruck auf niedrige CPU. Zum Beispiel können diese 3 Zeilen, die in Ihren Funktionskörper eingefügt werden, den Swiftparser zum Crawlen bringen.

let fullPath =  "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"
let spacesData  = NSDictionary(contentsOfFile: fullPath )! // as Dictionary<String, AnyObject>
let spaces : AnyObject   = spacesData["SpacesDisplayConfiguration"]!["Management Data"]!!["Monitors"]!![0]["Spaces"]!! 

println ( spaces )

aber wenn ich es in eine func stecke und es später aufrufe, ist swiftparser viel schneller

// some crazy typecasting here to silence the parser
// Autodetect of Type from Plist is very rudimentary, 
// so you have to teach swift your types
// i hope this will get improved in swift in future
// would be much easier if one had a xpath filter with
// spacesData.getxpath( "SpacesDisplayConfiguration/Management Data/Monitors/0/Spaces" ) as Array<*> 
// and xcode could detect type from the plist automatically
// maybe somebody can show me a more efficient way to do it
// again to make it nice for the swift parser, many vars and small statements
func getSpacesDataFromPlist() -> Array<Dictionary<String, AnyObject>> {
  let fullPath =  "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"

  let spacesData  = NSDictionary(contentsOfFile: fullPath )!    as Dictionary<String, AnyObject>
  let sdconfig    = spacesData["SpacesDisplayConfiguration"]    as Dictionary<String, AnyObject>
  let mandata     = sdconfig["Management Data"]                 as Dictionary<String, AnyObject> 
  let monitors    = mandata["Monitors"]                         as Array<Dictionary<String, AnyObject>> 
  let monitor     = monitors[0]                                 as Dictionary<String, AnyObject>
  let spaces      = monitor["Spaces"]                           as Array<Dictionary<String, AnyObject>>

  return spaces
}

func awakeFromNib() {
  ....
  ... typing here ...

  let spaces = self.getSpacesDataFromPlist()
  println( spaces) 
}

Swift und XCode 6.1 sind immer noch sehr fehlerhaft, aber wenn Sie diese einfachen Tricks befolgen, wird das Bearbeiten von Code wieder akzeptabel. Ich bevorzuge schnell viel, da es .h-Dateien entfernt und viel sauberere Syntax verwendet. Es werden immer noch viele Typumwandlungen wie "myVar as AnyObject" benötigt, aber das ist das kleinere Übel im Vergleich zur komplexen Ziel-C-Projektstruktur und -Syntax.

Auch eine andere Erfahrung, ich habe das SpriteKit ausprobiert, das Spaß macht, aber es ist ziemlich ineffizient, wenn Sie kein ständiges Repaint mit 60 fps benötigen. Die Verwendung alter CALayer ist für die CPU viel besser, wenn sich Ihre "Sprites" nicht so oft ändern. Wenn Sie den Inhalt der Ebenen nicht ändern, ist die CPU im Grunde genommen inaktiv. Wenn jedoch eine SpriteKit-App im Hintergrund ausgeführt wird, kann es vorkommen, dass die Videowiedergabe in anderen Apps aufgrund der unbegrenzten 60-fps-Aktualisierungsschleife stottert.

Manchmal zeigt xcode beim Kompilieren seltsame Fehler an, dann hilft es, in das Menü "Produkt> Reinigen" zu gehen und es erneut zu kompilieren. Dies scheint eine fehlerhafte Implementierung des Caches zu sein.

Eine weitere großartige Möglichkeit, das Parsen zu verbessern, wenn xcode mit Ihrem Code hängen bleibt, wird in einem anderen Stackoverflow-Beitrag hier erwähnt . Grundsätzlich kopieren Sie alle Inhalte aus Ihrer .swift-Datei in einen externen Editor und kopieren sie dann Funktion für Funktion zurück, um festzustellen, wo sich Ihr Engpass befindet. Dies hat mir tatsächlich geholfen, xcode wieder auf eine vernünftige Geschwindigkeit zu bringen, nachdem mein Projekt mit 100% CPU verrückt geworden war. Während Sie Ihren Code zurückkopieren, können Sie ihn umgestalten und versuchen, Ihre Funktionskörper kurz und Funktionen / Formulare / Ausdrücke einfach zu halten (oder in mehrere Zeilen aufzuteilen).

Automatische Vervollständigung da Xcode gebrochen 4. Bis Apple diese 2 Jahre alt Fehler zu beheben entscheidet, ist die einzige Lösung, leider ist der Code - Vervollständigung drehen OFF auf XCode-Einstellungen (erste Möglichkeit , das Bild unten).

Sie können die Fertigstellung weiterhin manuell durch Eingabe CTRL spaceoder ESCbei Bedarf genießen .

Dies ist die einzige Lösung, die jedes Mal in 100% der Fälle funktioniert.

Eine andere Sache, die ich kürzlich entdeckt habe, ist: Wenn Sie Plugins für Xcode verwenden, tun Sie dies nicht. Entfernen Sie sie alle. Sie verschlimmern das Problem.

Verwenden Sie Spotify? Ich habe Yosemite GM mit Xcode 6.1 GM auf einem iMac Mitte 2009 (2,66 GHz) mit dem gleichen Problem installiert. Ich habe festgestellt, dass ein Prozess namens "SpotifyWebHelper" immer rot markiert ist und nicht reagiert. Daher habe ich die Option "Start from Web" in deaktiviert spotify und jetzt scheint Xcode deutlich besser zu laufen.

Ich habe herausgefunden, dass das normalerweise passiert, wenn Sie:

• lange Ausdrücke in einer einzigen Aussage haben (siehe diese Antwort )
• Mischen Sie mehrere benutzerdefinierte Operatoren in einem einzigen Ausdruck

Der zweite Fall scheint in einer der neuesten xcode-Versionen behoben zu sein. Beispiel: Ich habe 2 benutzerdefinierte Operatoren <&&> und <||> definiert und in einem Ausdruck wie verwendet a <&&> b <&&> c <||> d. Das Aufteilen in mehrere Zeilen löste das Problem:

let r1 = a <&&> b
let r2 = r1 <&&> c
let r3 = r2 <||> d

Ich hoffe, dass Ihre Fälle von einer der beiden oben genannten abgedeckt werden ... Bitte geben Sie in beiden Fällen einen Kommentar ab

Ich hatte die gleichen Probleme sogar in Xcode 6.3

• super langsame Autovervollständigungen
• super langsame Indizierung
• enorme CPU-Auslastung durch Swift und SourceKitService
• enorme Speichernutzung durch SourceKitService

All dies geschah bereits in relativ kleinen Projekten. Ich habe alle Korrekturen ausprobiert, die ich finden konnte:

• Löschen von ~ / Library / Developer / Xcode / DerivedData / *
• Löschen von ~ / Library / Caches / com.apple.dt.Xcode / *
• Entfernen Sie alle "+" Zeichenfolgen, die kombiniert werden, aus dem Code
• Alle verdächtigen Wörterbuchdeklarationen wurden entfernt

Nichts davon hat in meinem Projekt wirklich geholfen.

Was mein Problem tatsächlich gelöst hat, war:

• Platzieren Sie jedes Ende jeder Klasse in einer eigenen Datei
• Platzieren jeder einzelnen Erweiterung in einer eigenen Datei (Class + ExtName.swift)
• Platzieren von "Swift-Methoden außerhalb der Klasse" in einer eigenen Datei

Jetzt habe ich eine CPU-Auslastung von nahezu Null, eine geringe Speichernutzung und anständig schnelle Abschlüsse.

Im Allgemeinen hat das Verschieben des Cache-Ordners (DerivedData) auf ein SSD-Laufwerk (insbesondere in meinem Fall - ein mit dem Thunderbolt-Exit verbundener äußerer Speicher) meine Xcode-Leistung erheblich verbessert. Die Kompilierungszeit und allgemeine Fragen rund um die App sind etwa zehnmal schneller. Außerdem wurde der gesamte Git-Ordner auf die SSD verschoben, wodurch die Git-Leistung erheblich verbessert wurde.

Es war ein Schmerz bis XCode 7.2.

Apple hat es in XCode 7.3 behoben und jetzt funktioniert es wie ein Zauber. Es ist superschnell und viel leistungsfähiger, da es ein bisschen wie die unscharfe Suche nach Dateien zu funktionieren scheint: Sie müssen nicht den genauen Anfang der Methode / Eigenschaft eingeben, damit sie in der Liste der Sätze erscheint.

Das Reduzieren aller Methoden hilft ein wenig.

Befehl-Alt-Umschalt-Links-Pfeil macht den Trick ...

Um aktuelle Methoden zu falten / zu entfalten oder wenn Strukturen verwenden:

Falten: Befehl-Alt-Links-Pfeil

Entfalten: Befehl-Alt-Rechts-Pfeil

SourceKitServiceEs ist auch etwas umständlich, mit Kommentaren im Code umzugehen, und die eingebetteten Kommentare verlangsamen ihn ebenfalls.

Wenn Sie es sich also leisten können, den massiven Klumpen eingebetteter Kommentare wie folgt zu entfernen:

/*
 * comment 
    /*
     * embedded comment
     */
 */

das kann definitiv auch helfen.

HINWEIS: In meinem Fall wurde mein Xcode 7.3.1 (7D1014) buchstäblich daran gehindert, einen Buchstaben einzugeben, wenn die Datei etwa 700 Kommentarzeilen mit eingebetteten Kommentaren enthielt. Anfangs habe ich diesen Block aus dieser .swiftDatei entfernt und Xcode ist wieder lebendig geworden. Ich habe versucht, meine Kommentare Teil für Teil wieder hinzuzufügen, indem ich eingebettete Kommentare entfernt habe. Es war immer noch langsamer als gewöhnlich, aber es zeigte eine deutlich bessere Leistung, wenn es keine eingebetteten Kommentare gab.

Ich hatte das gleiche Problem, bei dem das Tippen in einer bestimmten Klasse zurückblieb, und das stellte sich heraus

/* Long multiline comments */

verlangsamte das Tippen.