ios 带有 Swift 超慢输入和自动完成功能的 Xcode 6

Xcode 6 with Swift super slow typing and autocompletion

提问by mllm

Is it just me or Xcode 6 (6.0.1) with Swift seems to be super slowwhen you type your code, especially with autocompletion?

是我还是 Xcode 6 (6.0.1) 和 Swift在您键入代码时似乎超级慢，尤其是自动完成功能？

A normal Objective-C class, even if inside a Swift project, works almost the same as before, so it's Swift that kills it.

一个普通的 Objective-C 类，即使在 Swift 项目中，也几乎和以前一样工作，所以是 Swift 杀死了它。

Does anyone else experience the same inconvenience? Do you have any idea of how to improve performance?

有没有其他人遇到同样的不便？你知道如何提高性能吗？

• I tried to play with some settings but no luck.
• I've also of course tried restarting Xcode and the computer with no luck.
• No other heavy apps are open.

• 我试图玩一些设置，但没有运气。
• 我当然也尝试过重新启动 Xcode 和计算机，但没有成功。
• 没有其他重度应用程序打开。

I use a Mid 2009 Macbook Pro (2.26 GHz Intel Core 2 Duo) with 8GB RAM and SSD HD, which is not the newest thing at all, but still not a complete junk.

我使用的是 2009 年中的 Macbook Pro（2.26 GHz Intel Core 2 Duo）和 8GB RAM 和 SSD HD，这根本不是最新的东西，但仍然不是一个完整的垃圾。

It is a shame as I was excited to start using Swift and it is now really unbearable.

很遗憾，因为我很高兴开始使用 Swift，现在真的无法忍受。

Thoughts / tips?

想法/提示？

采纳答案by g8production - Daniele Gali8

• Quit Xcode and restart the Mac are not required but preferred.
• Delete the contentof the folder ~/Library/Developer/Xcode/DerivedData
• Delete the content~/Library/Caches/com.apple.dt.Xcode

• 退出 Xcode 并重新启动 Mac 不是必需的，但首选。
• 删除内容的文件夹〜/资源库/开发/的Xcode / DerivedData的
• 删除内容~/Library/Caches/com.apple.dt.Xcode

This is a temporally solution, but works greatly.

这是一个临时解决方案，但效果很好。

Below the script using Script Editor app.

在脚本下方使用脚本编辑器应用程序。

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

Alternatively, you can create an alias for your terminal like this:

或者，您可以为终端创建一个别名，如下所示：

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

You can add that to your ~/.bash_profileand then type xcodecleanon the command line every time you would like to clear those two folders.

您可以将其添加到您的~/.bash_profile，然后xcodeclean每次要清除这两个文件夹时在命令行上键入。

回答by Daniel Unterberger

I also experienced 100%+ CPU while typing some "simple" code. Some small tricks to make the swift-parser quicker by the way you structure your code.

在键入一些“简单”代码时，我还体验了 100%+ CPU。通过构建代码的方式使 swift-parser 更快的一些小技巧。

Don't use the "+" concatinator in strings. For me this triggers the slowness very quickly. Each new "+" brings the parser to a crawl, and it has to reparse the code everytime you add a new char somewhere in your function body.

不要在字符串中使用“+”连接符。对我来说，这会很快触发缓慢。每个新的“+”都会使解析器陷入困境，并且每次在函数体中的某处添加新字符时，它都必须重新解析代码。

Instead of:

代替：

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

Use the template-syntax which seems much more efficient to parse in swift:

使用在 swift 中似乎更有效解析的模板语法：

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

This way i basically notice no limit in strlen with inline vars "\(*)" .

这样我基本上注意到 strlen 与内联变量 "\(*)" 没有限制。

If you have calculations, which use + / * - then split them into smaller parts.

如果您有使用 + /* - 的计算，则将它们分成更小的部分。

Instead of:

代替：

var result = pi * 2 * radius 

use:

用：

var result  = pi * 2
    result *= radius

It might look less efficient, but the swift parser is much faster this way. Some formulas won't compile, if they have to many operations, even if they are mathematically correct.

它可能看起来效率较低，但这种方式的 swift 解析器要快得多。如果某些公式需要进行多次运算，则它们将无法编译，即使它们在数学上是正确的。

If you have some complex calculations then put it in a func. This way the parser can parse it once and does not have to reparse it everytime you change something in your function body.

如果你有一些复杂的计算，那么把它放在一个 func 中。这样解析器就可以解析它一次，而不必在每次更改函数体中的某些内容时重新解析它。

Because if you have a calculation in your function body then somehow the swift parser checks it everytime if the types, syntax etc. are still correct. If a line changes above the calculation, then some vars inside your calculation / formula might have changed. If you put it in an external function then it will be validated once and swift is happy that it will be correct and does not reparse it constantly, which is causing the high CPU usage.

因为如果你的函数体中有一个计算，那么 swift 解析器每次都会以某种方式检查它是否类型、语法等仍然正确。如果计算上方的一行发生变化，则计算/公式中的某些变量可能已更改。如果你把它放在一个外部函数中，那么它会被验证一次并且 swift 很高兴它是正确的并且不会不断地重新解析它，这会导致高 CPU 使用率。

This way i got from 100% on each keypress to low CPU while typing. For example this 3 lines put inline in your function body can bring the swiftparser to a crawl.

这样我在打字时从每次按键的 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 )

but if i put it in a func and call it later , swiftparser is much quicker

但是如果我把它放在一个 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 and XCode 6.1 is still very buggy, but if you follow these simple tricks, editing code becomes acceptable again. I prefer swift a lot, as it gets rid of .h files and uses much cleaner syntax. There is still many type-casting needed like "myVar as AnyObject" , but thats the smaller evil compared to complex objective-c project structure and syntax.

Swift 和 XCode 6.1 仍然有很多问题，但如果你遵循这些简单的技巧，编辑代码又变得可以接受了。我更喜欢 swift 很多，因为它摆脱了 .h 文件并使用更简洁的语法。仍然需要许多类型转换，例如 "myVar as AnyObject" ，但与复杂的objective-c 项目结构和语法相比，这是较小的邪恶。

Also another experience, i tried the SpriteKit, which is fun to use, but its quite in-efficient if you don't need a constant repaint at 60fps. Using old CALayers is much better for the CPU if your "sprites" don't change that often. If you don't change the .contents of the layers then CPU is basically idle, but if you have a SpriteKit app running in background, then videoplayback in other apps might start to stutter due to the hardlimited 60fps update-loop.

还有另一种体验，我尝试了 SpriteKit，它使用起来很有趣，但如果您不需要以 60fps 的速度持续重绘，它的效率非常低。如果您的“精灵”不经常更改，则使用旧的 CALayer 对 CPU 来说要好得多。如果您不更改图层的 .contents，那么 CPU 基本上处于空闲状态，但是如果您有一个 SpriteKit 应用在后台运行，那么由于硬限制 60fps 更新循环，其他应用中的视频播放可能会开始卡顿。

Sometimes xcode shows odd errors while compiling, then it helps to go into menu "Product > Clean" and compile it again, seems to be a buggy implementation of the cache.

有时xcode在编译时会显示奇怪的错误，然后进入菜单“产品>清理”并再次编译它会有所帮助，这似乎是缓存的错误实现。

Another great way to improve parsing when xcode gets stuck with your code is mentioned in another stackoverflow post here. Basically you copy all contents from your .swift file into an external editor, and then function by function copy it back and see where your bottleneck is. This actually helped me to get xcode to a reasonable speed again, after my project went crazy with 100% CPU. while copying your code back, you can refactor it and try to keep your function-bodies short and functions/formulars/expressions simple (or split in several lines).

此处的另一篇 stackoverflow 帖子中提到了当 xcode 卡在您的代码中时改进解析的另一种好方法。基本上，您将 .swift 文件中的所有内容复制到外部编辑器中，然后逐个功能地将其复制回来，看看您的瓶颈在哪里。这实际上帮助我让 xcode 再次达到合理的速度，在我的项目在 100% CPU 的情况下变得疯狂之后。在复制你的代码时，你可以重构它并尝试保持你的函数体简短和函数/公式/表达式简单（或分成几行）。

回答by DuckDucking

Autocomplete is broken since Xcode 4. Until Apple decides to fix this 2 years old bug, the only solution, unfortunately, is to turn code completion OFFon XCode's preferences (first option of the pic below).

因为Xcode的4自动完成被打破直到苹果决定来解决这个2岁的错误，唯一的解决办法，可惜，就是把代码完成关闭在Xcode的偏好（以下PIC的第一个选项）。

You can continue to enjoy completion manually by typing CTRL spaceor ESCwhen you need it.

您可以通过键入CTRL space或ESC在需要时继续手动完成。

This is the only solution that works every time for 100% of the cases.

这是每次都适用于 100% 情况的唯一解决方案。

Another thing I have discovered recently is: if you use plugins on Xcode, don't. Remove them all. They make the problem worse.

我最近发现的另一件事是：如果您在 Xcode 上使用插件，请不要。将它们全部删除。他们使问题变得更糟。

回答by Eugenio Baglieri

Are you using Spotify? I installed Yosemite GM with Xcode 6.1 GM on an iMac mid 2009 (2.66Ghz) having the same problem.I found that a process called "SpotifyWebHelper" is always marked red as not responding, so i disabled the option "start from web" in spotify and now Xcode seem to run significantly better.

你在使用 Spotify 吗？我在 2009 年年中的 iMac (2.66Ghz) 上安装了带有 Xcode 6.1 GM 的 Yosemite GM，有同样的问题。我发现一个名为“SpotifyWebHelper”的进程总是被标记为红色没有响应，所以我禁用了选项“从网络开始” Spotify 和现在 Xcode 似乎运行得更好。

回答by Antonio

I found out that usually happens when you:

我发现这通常发生在您：

• have long expressions in a single statement (see this answer)
• mix multiple custom operators in a single expression

• 在单个语句中有很长的表达式（请参阅此答案）
• 在单个表达式中混合多个自定义运算符

The 2nd case seems to be fixed in one of the latest xcode releases. Example: I defined 2 custom operators <&&> and <||>, and used in an expression like a <&&> b <&&> c <||> d. Splitting to multiple lines solved the problem:

第二种情况似乎已在最新的 xcode 版本之一中得到修复。示例：我定义了 2 个自定义运算符 <&&> 和 <||>，并在像a <&&> b <&&> c <||> d. 拆分为多行解决了问题：

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

I hope that your cases is covered by one of the 2 above... please post a comment either case

我希望您的案例包含在上述 2 个案例之一中...请发表评论任一案例

回答by Matej Ukmar

I had the same issues even in Xcode 6.3

即使在 Xcode 6.3 中我也有同样的问题

• super slow autocompletions
• super slow indexing
• enormous CPU usage by swift and SourceKitService
• enormous Memory usage by SourceKitService

• 超慢自动补全
• 超慢索引
• swift 和 SourceKitService 占用大量 CPU
• SourceKitService 占用大量内存

All this was happening even in relatively small project. I tried all the fixes I could find:

即使在相对较小的项目中，这一切也发生了。我尝试了所有我能找到的修复：

• deleting ~/Library/Developer/Xcode/DerivedData/*
• deleting ~/Library/Caches/com.apple.dt.Xcode/*
• remove all "+" String combining from the code
• removed all suspicious dictionary declarations

• 删除 ~/Library/Developer/Xcode/DerivedData/*
• 删除 ~/Library/Caches/com.apple.dt.Xcode/*
• 从代码中删除所有“+”字符串组合
• 删除了所有可疑的字典声明

None of these actually helped in my project.

这些都没有真正帮助我的项目。

What actually solved my problem was:

真正解决了我的问题的是：

• placing each end every class in its own file
• placing each and every extension in its own file (Class+ExtName.swift)
• placing "out of class swift methods" in its own file

• 将每个类放在自己的文件中
• 将每个扩展名放在自己的文件中 (Class+ExtName.swift)
• 将“类外快速方法”放在自己的文件中

Now I have close to zero CPU usage, low memory usage, and decently fast completions.

现在我的 CPU 使用率接近于零，内存使用率低，并且完成速度相当快。

回答by brkeyal

Generally, moving the cache folder (DerivedData) to a SSD drive (specifically in my case - an outer storage connected to thunderbolt exit) has dramatically improved my Xcode performance.. Compilation time and general wondering around the app is about 10 time faster.. Also moved the whole git folder to the SSD, which dramatically improved git performance.

通常，将缓存文件夹 (DerivedData) 移动到 SSD 驱动器（特别是在我的情况下 - 连接到 Thunderbolt 出口的外部存储）大大提高了我的 Xcode 性能。编译时间和应用程序周围的一般疑惑大约快 10 倍。还将整个 git 文件夹移动到了 SSD，这大大提高了 git 性能。

回答by Bioche

It was a pain until XCode 7.2.

在 XCode 7.2 之前，这很痛苦。

Apple fixed it in XCode 7.3 and now it works like a charm. It's super fast and much more powerful as it seems to work a bit like the fuzzy search of files : you don't have to actually type the exact beginning of the method/property for it to appear in the list of propositions.

Apple 在 XCode 7.3 中修复了它，现在它就像一个魅力。它超级快速且功能强大，因为它似乎有点像文件的模糊搜索：您不必实际键入方法/属性的确切开头，以便它出现在命题列表中。

回答by rowdyruckus

Collapsing all methods helps a little.

折叠所有方法会有所帮助。

command-alt-shift-left arrow will do the trick...

command-alt-shift-left 箭头会起作用......

To fold/unfold current methods or if structures use:

折叠/展开当前方法或结构使用：

Fold: command-alt-left arrow

折叠：command-alt-left 箭头

Unfold: command-alt-right arrow

展开：command-alt-右箭头

回答by holex

SourceKitServiceis also kinda clumsy to deal with comments in the code and the embedded commentsslow it down too.

SourceKitService处理代码中的注释也有点笨拙，嵌入的注释也会减慢它的速度。

so if you can afford to remove the massive blob of embedded comments like this:

所以如果你能负担得起像这样删除大量的嵌入评论：

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

that can definitely help as well.

这也绝对有帮助。

---

---

NOTE:in my case my Xcode 7.3.1 (7D1014) was literally blocked me typing any letter when the file had about 700 lines of comment with embedded comments. initially I removed that block from that .swiftfile and Xcode has become alive again. I tried added my comments back part by part by removing embedded comments, it was still slower than usual but it shown significantly better performance if there were no embedded comments.

注意：在我的例子中，当文件有大约 700 行带有嵌入注释的注释时，我的 Xcode 7.3.1 (7D1014) 实际上阻止了我输入任何字母。最初我从该.swift文件中删除了该块，Xcode 再次活跃起来。我尝试通过删除嵌入的评论来部分地添加我的评论，它仍然比平时慢，但如果没有嵌入的评论，它的性能会显着提高。