Xcode 6与Swift超慢input和自动完成
是只是我或Xcode 6（6.0.1）与Swift似乎是超级慢，当你input你的代码，尤其是自动完成？
一个普通的Objective-C类，即使在一个Swift项目中，也几乎和以前一样，所以它是Swift杀死它的。
有没有其他人遇到同样的不便？ 你有什么想法如何提高性能？
- 我试图玩一些设置，但没有运气。
- 我当然也尝试重新启动Xcode和电脑没有运气。
- 没有其他重型应用程序是开放的
我使用的是2009年中期的MacBook Pro（2.26 GHz Intel Core 2 Duo），配备了8GB内存和SSD HD，虽然不是最新的产品，但仍然不是一个完整的垃圾。
我很兴奋地开始使用Swift，这实在令人惭愧，现在真的让人无法忍受。
想法/提示？
- 退出Xcode并重新启动Mac不是必需的，但首选。
- 删除〜/ Library / Developer / Xcode / DerivedData文件夹的内容
- 删除内容 〜/ Library / Caches / com.apple.dt.Xcode
这是一个暂时的解决scheme，但工作很大。
使用脚本编辑器应用程序的脚本下面
tell application "Terminal" do script "rm -frd ~/Library/Developer/Xcode/DerivedData/*" do script "rm -frd ~/Library/Caches/com.apple.dt.Xcode/*" end tell 或者，您可以为您的terminal创build一个别名，如下所示：
alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* && rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
您可以将其添加到~/.bash_profile ，然后在每次要清除这两个文件夹时在命令行上键入xcodeclean 。
在input一些“简单”的代码时，我也经历了100％+ CPU。 一些小技巧，使你的代码结构快速parsing器更快。
不要在string中使用“+”concatinator。 对我来说，这很快就会引起缓慢。 每个新的“+”都会带来parsing器的抓取，并且每次在函数体内的某处添加一个新的字符时，都必须重新分析代码。
代替：
var str = "This" + String(myArray.count) + " is " + String(someVar)
使用模板语法，在swift中parsing似乎更有效率：
var str = "This \(myArray.count) is \(someVar)"
这样，我基本上注意到内联variables“\（*）”在strlen中没有限制。
如果你有计算，使用+ / * – 然后将它们分成较小的部分。
代替：
var result = pi * 2 * radius
使用：
var result = pi * 2 result *= radius
它可能看起来效率较低，但快速parsing器是这样快得多。 一些公式不会编译，如果它们有很多操作，即使它们在math上是正确的。
如果你有一些复杂的计算，然后把它放在一个函数。 这样parsing器可以parsing一次，而不必在每次更改函数体中的某些内容时重新parsing它。
因为如果你在函数体中有一个计算，那么如果types，语法等仍然是正确的，那么swift分析器每次都会检查它。 如果一条线在计算之上改变，那么计算/公式中的一些variables可能已经改变。 如果你把它放在一个外部函数中，那么它将被validation一次，swift很高兴它将是正确的并且不会不断地重新parsing它，这导致了高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 )
但是如果我把它放在一个函数中，稍后调用它，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仍然是非常麻烦的，但是如果你遵循这些简单的技巧，编辑代码就可以再次被接受。 我更喜欢swift，因为它删除了.h文件，并使用更清晰的语法。 还有很多像“myVar as AnyObject”这样的types转换，但是比起复杂的objective-c项目结构和语法来说，更小的恶意。
另外还有一个经验，我尝试了SpriteKit，这很有趣，但是如果你不需要60fps的持续重绘的话，它效率很高。 如果你的“精灵”不经常改变的话，使用旧的CALayer对于CPU来说会更好。 如果不更改图层的内容，则CPU基本上处于空闲状态，但是如果您有SpriteKit应用程序在后台运行，则其他应用程序中的video播放回放可能会由于60fps更新循环而出现故障。
有时xcode在编译时显示奇怪的错误，然后进入“Product> Clean”菜单并重新编译，这似乎是caching的一个错误的实现。
另一个改善parsing当xcode卡住你的代码的好方法是在另一个stackoverflow后提到这里 。 基本上，您将.swift文件中的所有内容复制到外部编辑器中，然后通过函数function将其复制回来，看看您的瓶颈在哪里。 这实际上帮助我得到了一个合理的速度再次Xcode，我的项目疯狂与100％的CPU。 在复制你的代码的时候，你可以重构它，并尽量保持你的函数体的简洁性和函数/公式/expression式的简单（或者分成几行）。
自从Xcode 4以来，自动完成function已经被破坏了。直到苹果决定修复这个2年前的bug，唯一的解决scheme就是在XCode的首选项（图片的第一个选项）上closures代码。
您可以通过在需要时键入CTRL space或ESC来手动继续欣赏完成。
这是每次100％的情况下唯一的解决scheme。
我最近发现的另一件事是：如果你在Xcode上使用插件，不要。 全部删除。 他们使问题变得更糟。
你在使用Spotify吗？ 我在2009年年中（2.66Ghz）安装了Xcode 6.1 GM的Yosemite GM，具有相同的问题。我发现一个名为“SpotifyWebHelper”的进程总是被标记为红色，因此我禁用了“从networking启动”选项spotify，现在Xcode似乎运行得更好。
即使在Xcode 6.3中也有同样的问题
- 超级慢自动完成
- 超慢速索引
- 巨大的CPU使用swift和SourceKitService
- 巨大的内存使用SourceKitService
所有这一切都发生在相对较小的项目中。 我尝试了所有可以find的修复：
- 删除〜/ Library / Developer / Xcode / DerivedData / *
- 删除〜/ Library / Caches / com.apple.dt.Xcode / *
- 从代码中删除所有“+”string组合
- 删除了所有可疑的字典声明
这些都没有帮助我的项目。
究竟是什么解决了我的问题是：
- 将每个类的每一端放在自己的文件中
- 将每个扩展名放在自己的文件（Class + ExtName.swift）
- 在自己的文件中放置“超出课堂快捷方式”
现在我的CPU使用率接近零，内存使用率低，并且体积快速完成。
一般来说，将caching文件夹（DerivedData）移动到SSD驱动器（特别是在我的情况下 – 连接到Thunderbolt出口的外部存储）显着提高了我的Xcode性能。编译时间和围绕应用程序的一般疑问大约快10倍。还将整个git文件夹移动到SSD，这极大地改善了git的性能。
在XCode 7.2之前这是一个痛苦的事情。
苹果公司在XCode 7.3中修复了它，现在它像一个魅力。 它的速度超快，function也更强大，因为它看起来有点像文件的模糊search：你不必真正input方法/属性的确切开始，以使它出现在命题列表中。
折叠所有方法有一点帮助。
命令ALTTLE左箭头将做的伎俩…
折叠/展开当前的方法，或者如果结构使用：
折叠：命令左转箭头
展开：command-alt-right箭头
我发现，通常情况下，当你：
- 在一个单独的陈述中有很长的expression式（见这个答案 ）
- 在一个expression式中混合多个自定义操作符
第二种情况似乎是在最新的xcode版本中修复的。 示例：我定义了2个自定义运算符<&&>和<||>，并用于像a <&&> b <&&> c <||> d这样的expression式中。 分成多行解决了这个问题：
let r1 = a <&&> b let r2 = r1 <&&> c let r3 = r2 <||> d
我希望你的情况是由上述2中的一个覆盖…请发表任何意见
SourceKitService在处理代码中的注释方面也SourceKitService笨拙， embedded的注释也会让它慢下来。
所以如果你能负担得起这样的embedded式评论大量blob：
/* * comment /* * embedded comment */ */
这绝对可以帮助。
注意：在我的情况下，我的Xcode 7.3.1（7D1014）字面上是封锁我input任何字母时，该文件约700行评论与embedded评论。 最初我从那个.swift文件中删除了这个块，Xcode又重新开始了。 我试图通过删除embedded的评论来逐个添加我的评论，但仍然比平常慢，但是如果没有embedded的评论，它显示出显着更好的性能。
我有同样的问题，打字在一个特定的类落后，结果
/* Long multiline comments */
正在放缓打字。
