Xcode 6とSwiftの超低速タイピングおよびオートコンプリート


114

特にオートコンプリートを使用してコードを入力すると、Swiftを使用したXcode 6(6.0.1)だけが非常に遅くなりますか?

通常のObjective-Cクラスは、たとえSwiftプロジェクト内であっても、以前とほとんど同じように機能するため、Swiftがそれを強制終了します。

他の誰かが同じ不便を経験していますか?パフォーマンスを向上させる方法について何か考えがありますか?

  • いくつかの設定で遊んでみましたが、運がありませんでした。
  • もちろん、Xcodeとコンピューターを再起動しても運が悪かった。
  • 他の重いアプリは開いていません。

私は、8GB RAMとSSD HDを搭載したMid 2009 Macbook Pro(2.26 GHz Intel Core 2 Duo)を使用しています。

私がSwiftを使い始めることに興奮していて、今は本当に耐えられないのは残念です。

考え/ヒント?


1
私はあなたと同じ問題を抱えています。Xcodeから「SourceKitが終了し、エディターが一時的に制限されている」と
よく言われる

ええ、これはまた別の問題ですが、それらが関連しているとは思えません。そのエラーが起こっているときでさえ、それは遅かった。
mllm 2014

1
それらは関連していると確信しています。ベータ5では、そのメッセージがさらに頻繁に表示され、提案が機能しなかったときにいつでも表示されました。(文字を入力してEscキーを押して提案をトリガーしたとき)
idmean

1
私は同じ問題を抱えています。私のXCodeはCPUの300%以上を使用し、私のMacbook網膜をかたつむりの速度に落とします。私は今日、ほとんど盲目的にタイプし、xcodeが完了するのを待ちます。
pkuhar 2014

1
2011年後半の8 GB RAMとSSDを搭載した15.6インチMacBook Proでも同じ問題が発生します。タイムコードの完了の90%でXcodeがフリーズします。アクティビティモニターを確認すると、CPU使用率が最大200%と表示されます。数分
isair

回答:


86
  • Xcodeを終了してMacを再起動する必要はありませんが、推奨されます。
  • フォルダー〜/ Library / Developer / Xcode / DerivedData のコンテンツを削除します
  • コンテンツを削除します〜/ Library / Caches / com.apple.dt.Xcode

これは一時的な解決策ですが、大きく機能します。

スクリプトエディターアプリを使用したスクリプトの下。

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

または、次のように端末のエイリアスを作成できます。

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

あなたは、あなたにそれを追加することができます~/.bash_profileし、次に入力しxcodeclean、コマンドラインで使用すると、これらの2つのフォルダをクリアしたいたびに。


まあ、完璧とは言えませんが、ソリューションによって大幅に改善されているように見えます。かなり長い間、これはおそらくそれが得ることができる最高のものなので、私はマークが解決することになるでしょう。他の人の話を聞いて幸せになります...どうもありがとう!
mllm 2014

私のラップトップがこれら2つのフォルダーからすべてのコンテンツを削除するのに1分近くかかりました。Xcodeでのインデックス作成に30秒もかかりません。
Eneko Alonso

入力やオートコンプリートを速くすることはできませんでしたが、Macからかなりのスペースを解放するのに役立ちました。
Scott Zhu

この回答は、オートコンプリート機能、stackoverflow.com / a / 29849869/1213267
Scott Zhu

13

「単純な」コードを入力しているときにも、100%以上のCPUを経験しました。コードを構造化する方法で迅速なパーサーをより速くするためのいくつかの小さなトリック。

文字列で「+」コンカチネータを使用しないでください。私にとって、これは非常に迅速に遅さを引き起こします。新しい「+」はパーサーをクロールし、関数本体のどこかに新しい文字を追加するたびにコードを再解析する必要があります。

の代わりに:

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

迅速に解析する方がはるかに効率的であるように見えるテンプレート構文を使用します。

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

このようにして、基本的にインライン変数「\(*)」を使用したstrlenには制限がないことに気付きます。

+ / *-を使用する計算がある場合は、それらを小さな部分に分割します。

の代わりに:

var result = pi * 2 * radius 

使用する:

var result  = pi * 2
    result *= radius

見た目は効率的ではないかもしれませんが、Swiftパーサーはこの方法の方がはるかに高速です。数式が数学的に正しい場合でも、多くの演算を実行する必要がある場合、一部の数式はコンパイルされません。

いくつかの複雑な計算がある場合は、関数に入れます。このようにして、パーサーはそれを一度解析でき、関数本体で何かを変更するたびにそれを再解析する必要はありません。

関数本体に計算がある場合、型、構文などがまだ正しいかどうか、どういうわけか迅速なパーサーが毎回それをチェックするからです。計算の上で線が変化する場合は、計算/数式内の一部の変数が変更されている可能性があります。外部関数に配置すると、検証が1​​回行われ、swiftはそれが正しく、常に再解析されないことに満足しており、CPU使用率が高くなっています。

このようにして、入力中にキーを押すたびに100%から低CPUになりました。たとえば、関数本体にインラインで配置されたこの3行は、swiftparserをクロールさせる可能性があります。

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 )

それをfuncに入れて後で呼び出すと、swiftparserの方がはるかに高速です

// 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とXCode 6.1はまだ非常にバグが多いですが、これらの簡単なトリックに従うと、コードの編集が再び受け入れられるようになります。.hファイルを取り除き、よりすっきりした構文を使用するので、私は多くを迅速に好みます。"myVar as AnyObject"のように多くの型キャストが必要ですが、それは複雑なObjective-Cプロジェクトの構造と構文に比べて小さな悪です。

また、別の経験として、使用するのが楽しいSpriteKitを試しましたが、60 fpsで一定の再描画が必要ない場合は、非常に非効率的です。「スプライト」が頻繁に変更されない場合は、古いCALayersを使用する方がCPUにとってはるかに優れています。レイヤーの.contentsを変更しない場合、CPUは基本的にアイドルですが、SpriteKitアプリがバックグラウンドで実行されている場合、他のアプリでのビデオ再生が、60fpsの更新ループがハード制限されているために途切れ始める可能性があります。

コンパイル中にxcodeが奇妙なエラーを表示することがあるので、メニューの[Product]> [Clean]に移動して再度コンパイルすると、キャッシュのバグのある実装のようです。

xcodeがコードに行き詰まった場合の解析を改善するもう1つの優れた方法は、こちらの別のスタックオーバーフローの投稿に記載されています。基本的に、すべてのコンテンツを.swiftファイルから外部エディターにコピーし、関数ごとにコピーして、ボトルネックの場所を確認します。これは実際に、私のプロジェクトが100%のCPUでクレイジーになった後、xcodeを再び妥当な速度に戻すのに役立ちました。コードをコピーして戻している間、コードをリファクタリングして、関数本体を短くし、関数/式/式を単純なままにする(または複数の行に分割する)ことができます。


非常に徹底した答え。いくつかの提案は「応急処置」として素晴らしいかもしれませんが、実際には、Xcodeが大きな手間をかけずに単純に機能するとは期待できませんか?
mllm 2014年

1
残念ながら、xcode 6.1 + swiftは非常に不安定なので、これらの「ハック」が必要です。Appleはswiftとxcodeを修正する必要があります。しかし、swiftはプログラミングに非常に適しているため、短期的には、これがCPU使用率を抑える唯一の方法です。
Daniel Unterberger 2014年

私はあなたが提案するすべての可能な変更を加えましたが、残念ながら私のオートコンプリートはまだうまくいきません。if節の省略表現も問題を引き起こす可能性があるのではないかと思います。私はリターンを意味します(a == b)?x:y
Ilker Baltaci 2014年

まあ、IDEを幸せにする特定の方法でコードを書くのは本当のナンセンスです
Andrey Gordeev

10

オートコンプリートはXcode 4以降で機能しなくなりました。Appleがこの2年前のバグを修正するまで、残念ながら、唯一の解決策はXCodeの設定でコード補完をオフにすることです(下の写真の最初のオプション)。

入力するCTRL spaceESC、必要なときに手動で完了を楽しむことができます。

これは、ケースの100%で常に機能する唯一のソリューションです。

ここに画像の説明を入力してください

私が最近発見したもう1つのことは、Xcodeでプラグインを使用する場合は使用しないことです。それらをすべて削除します。彼らは問題を悪化させます。


5

Spotifyを使用していますか?同じ問題が発生する2009年中頃(2.66Ghz)のiMacにXcode 6.1 GMを搭載したヨセミテGMをインストールしました。 Spotifyを使用すると、Xcodeの実行が大幅に向上するようです。


興味深いですが、私にとってはSpotify関連ではありません...しかし、それはおそらく「通常の」パフォーマンスの問題、つまり、より多くのリソースをクリアすることでよりうまく機能することを示しています。提供できるリソースがなくなったので悲しいです(新しいMacのお金は別として)。
mllm 2014年

2

通常、次の場合に発生することがわかりました。

  • 1つのステートメントに長い式がある(この回答を参照)
  • 1つの式に複数のカスタムオペレーターを混在させる

2番目のケースは、最新のxcodeリリースの1つで修正されているようです。例:2つのカスタム演算子<&&>と<||>を定義し、などの式で使用しましたa <&&> b <&&> c <||> d。複数行に分割すると問題が解決しました:

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

あなたのケースが上記の2つのいずれかでカバーされていることを願っています...どちらのケースでもコメントを投稿してください


5
残念ながら、それは何もないまったく新しいクリーンプロジェクトでも発生し、「var s:Stri ...」のような単純なものを入力するだけです。「St」と入力し始めるとすぐに、補完候補を検索すると遅くなります。
mllm

間違いなく私にとってはオペランドです。同じ行に複数のオペランドがあると、その原因になります。答えてくれてありがとう。これが正しい答えになるはずです
ケサバ2014年

2

Xcode 6.3でも同じ問題が発生しました

  • 超遅いオートコンプリート
  • 超低速インデックス
  • swiftとSourceKitServiceによる膨大なCPU使用率
  • SourceKitServiceによる膨大なメモリ使用量

これはすべて、比較的小さなプロジェクトでも起こりました。私は見つけることができるすべての修正を試しました:

  • 〜/ Library / Developer / Xcode / DerivedData / *の削除
  • 〜/ Library / Caches / com.apple.dt.Xcode / *の削除
  • コードから結合しているすべての「+」文字列を削除する
  • 疑わしいすべての辞書宣言を削除

これらのどれも実際に私のプロジェクトに役立ちませんでした。

実際に私の問題を解決したのは:

  • 各端を独自のファイルにすべてのクラスを配置する
  • それぞれの拡張子を独自のファイル(Class + ExtName.swift)に配置する
  • 独自のファイルに「クラス外の迅速なメソッド」を配置する

これで、CPU使用率がゼロに近く、メモリ使用量が少なく、完了がかなり高速です。


2

一般に、キャッシュフォルダー(DerivedData)をSSDドライブ(具体的には、私の場合-サンダーボルトの出口に接続された外部ストレージ)に移動すると、Xcodeのパフォーマンスが劇的に向上しました。コンパイル時間と、アプリに関する一般的な疑問は、約10倍高速です。また、gitフォルダー全体をSSDに移動しました。これにより、gitのパフォーマンスが劇的に向上しました。


実際、元の問題では、SSDドライブを搭載したMacを既にアップグレードしており、そのすべてがそこから実行されていました。OS、それでも問題がありました
mllm

2

XCode 7.2まで苦労しました。

AppleはXCode 7.3でそれを修正し、今は魅力のように動作します。ファイルのあいまい検索に少し似ているように見えるため、非常に高速ではるかに強力です。命題のリストに表示するために、メソッド/プロパティの正確な先頭を実際に入力する必要はありません。


2

すべてのメソッドを折りたたむと少し役立ちます。

command-alt-shift-left矢印でうまくいきます...

現在のメソッドを折りたたむ/展開するには、または構造が使用する場合:

折りたたみ:command-alt-左矢印

展開:command-alt-right矢印


1

SourceKitServiceまた、コード内のコメントを処理するのは少し不格好であり、埋め込まれたコメントによっても遅くなります。

したがって、次のような埋め込みコメントの大量の塊を削除する余裕がある場合:

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

それも間違いなく役立ちます。


注:私の場合、ファイルにコメントが埋め込まれた約700行のコメントが含まれている場合、私のXcode 7.3.1(7D1014)は文字どおりブロックされました。最初に、そのブロックをその.swiftファイルから削除しましたが、Xcodeは再び生きています。埋め込みコメントを削除して、コメントを少しずつ追加してみましたが、それでも通常より遅くなりましたが、埋め込みコメントがない場合は、パフォーマンスが大幅に向上しました。


1

入力が特定のクラスで遅れているのと同じ問題があり、それが判明しました

/* Long multiline comments */

タイピングが遅くなっていました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.