只是我或Xcode 6（6.0.1）与斯威夫特似乎是超慢当你输入你的代码，尤其是自动完成？Xcode 6与斯威夫特超慢输入和自动完成
一个普通的Objective-C类，即使在Swift项目中，其工作原理几乎与以前相同，所以它是Swift杀死它的。
没有其他人遇到同样的不便吗？你对如何提高性能有任何想法吗？
我使用的是8GB RAM和SSD HD的2009年中期Macbook Pro（2.26 GHz Intel Core 2 Duo），它并不是最新的产品，但仍然不是一个完整的垃圾。
这是一个耻辱，因为我很兴奋地开始使用Swift，它现在真的无法忍受。
想法/提示？
这是一个暂时的解决方案，但工程很大。
使用脚本编辑器应用程序的脚本下方。
alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* && rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
您可以添加到您的~/.bash_profile，然后在命令行中键入xcodeclean每次你想清楚了这些：
tell application "Terminal"
do script "rm -frd ~/Library/Developer/Xcode/DerivedData/*"
do script "rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
end tell
或者，你可以为你的终端这样创建别名两个文件夹。
好吧，尽管它并不完美，但它确实看起来像您的解决方案显着改善了它。 我要说的是解决问题，因为在相当长的一段时间后，这可能是最好的解决方案。会很高兴听到其他人... 非常感谢！ – mllm 2014-12-28 00:17:09
我的笔记本电脑花了几分钟时间从这两个文件夹中删除所有内容。索引Xcode现在需要30秒。 – 2015-05-07 00:06:03
它并没有让我的打字和自动补全更快，但它确实帮助我从我的Mac上腾出了很多空间。 – 2015-12-20 07:01:05
我发现，通常发生在你：
的第二种情况似乎是在最新的xcode版本中修复的。示例：我定义了2个自定义运算符< & &>和< ||>，并用于像a <&&> b <&&> c <||> d这样的表达式中。拆分为多行解决了这个问题：
let r1 = a <&&> b
let r2 = r1 <&&> c
let r3 = r2 <||> d
我希望你的情况下，由上述2的一个覆盖......请您正在使用Spotify的发表评论，无论是哪种情况
？ 我在2009年中期（2.66Ghz）安装了Xcode 6.1 GM的Yosemite GM，它具有相同的问题。我发现一个名为“SpotifyWebHelper”的进程总是标记为红色，因此我禁用了“从网页开始”选项，在Spotify中，现在Xcode似乎运行得更好。
有趣的，但对我来说它不是Spotify相关... 但它也可能表明它只是一个“常见”性能问题 - 意思是 - 清除更多资源，它会更好地工作。这很让人伤心，因为我没有任何资源可以提供（除了在新Mac上的资金外）。 – mllm 2014-10-08 10:18:33
我在输入一些“简单”代码时也经历了100％+ CPU。一些小巧的技巧可以让您的代码更快速地构建swift-parser。
不要在字符串中使用“+”concatinator。对我来说，这很快就会引起缓慢。 每个新的“+”都会使解析器进行爬网，并且每次在函数体中的某处添加新的字符时，都必须重新解析代码。
相反的：
var str = "This" + String(myArray.count) + " is " + String(someVar)
使用的模板语法，这似乎更有效的迅速解析：
这样，我基本上注意到的strlen没有限制使用内联瓦尔“\ （*）“。
如果您有计算，使用+/* - 然后将它们分成较小的部分。
相反的：
var result = pi * 2 * radius
使用：
var result = pi * 2
result *= radius
它可能看起来不那么高效，但迅速解析器快得多这种方式。 某些公式不会编译，如果它们需要很多操作，即使它们在数学上是正确的。
如果你有一些复杂的计算，然后把它放在一个func。通过这种方式，解析器可以解析它一次，并且不必在每次更改函数体中的某些内容时重新解析该解析器。
因为如果你在函数体中有一个计算，那么如果类型，语法等仍然是正确的，那么swift分析器每次都会检查它。如果一条线在计算之上改变，那么计算/公式中的一些变量可能已经改变。如果你把它放在一个外部函数中，那么它将被验证一次，并且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)
}
雨燕的XCode 6.1仍然是非常错误的，但如果你遵循这些简单的技巧，编辑代码再次变得可以接受我更喜欢swift，因为它摆脱了.h文件，并使用更清晰的语法。还有很多类型转换需要像“myVar as AnyObject”那样，但是与复杂的objective-c项目结构和语法相比，这是更小的恶意。另一个经验，我尝试了SpriteKit，这很有趣，但它的效率很高，如果你不需要60fps的持续重绘。如果你的“精灵”不经常改变，使用旧的CALayers对于CPU来说会更好。如果你没有改变图层的内容，那么CPU基本上是空闲的，但是如果你有一个SpriteKit应用程序在后台运行，那么其他应用程序中的视频播放可能会由于60fps更新循环而受到影响。
有时xcode在编译时显示奇怪的错误，那么它有助于进入菜单“产品>清理”并再次编译，似乎是缓存的错误实现。
另一个改善解析xcode遇到你的代码时的另一个好方法是在另一个stackoverflow帖子here中提到。基本上你会复制你的所有内容。swift文件转换为外部编辑器，然后通过函数功能复制它并查看瓶颈位置。这实际上帮助我在xcode恢复到合理的速度后，在我的项目100％CPU疯狂后。在将代码复制回来时，可以对其进行重构，并尽量保持函数体的简短性，并简化函数/公式/表达式（或分成几行）。
非常全面的答案。也许有些建议对于“急救”来说非常棒，但是真的，我们不希望Xcode只是在没有经历巨大麻烦的情况下工作吗？ – mllm 2014-11-02 09:32:35
不幸的是xcode 6.1 + swift很不稳定，所以需要这些“黑客”。苹果应该修复swift和xcode。但swift非常适合编程，所以在短期内这是保持CPU使用率不变的唯一方法。 – 2014-11-03 20:35:44
我提出了所有可能的修改建议，但不幸的是我的自动完成仍然很糟糕。我怀疑速记如果子句可能会造成麻烦。任何人都可以承认这一点？我的意思是返回（a == b）？ x：y – 2014-11-19 18:25:53
以来的Xcode 4.自动完成被打破直到苹果决定来解决这个2岁的错误，唯一的解决办法，不幸的是，开启Xcode的喜好代码完成OFF（以下PIC的第一个选项）。
当您需要时，您可以通过输入CTRL space或ESC手动继续享受完成。
这是唯一的解决方案，每次100％的情况下工作。
我最近发现的另一件事情是：如果你在Xcode中使用插件，不要。全部删除它们。他们让问题变得更糟。
我有同样的问题，甚至在Xcode 6.3
所有这些都发生在相对较小的项目中。我尝试了所有的补丁我能找到的：
无相结合。
究竟解决了我的问题是：
现在我已经接近零CPU占用率，低内存占用，以及体面快速的完成。
通常，将缓存文件夹（DerivedData）移动到SSD驱动器（特别是在我的情况下 - 连接到Thunderbolt出口的外部存储器），显着提高了我的Xcode性能。编译时间和围绕该应用程序的一般疑问大约是10时间更快..也将整个git文件夹移动到SSD，这极大地提高了git的性能。
其实在原来的问题，我已经升级我的Mac与SSD驱动器和一切从它运行。操作系统，仍然有问题 – mllm 2016-02-03 09:39:25
在XCode 7.2之前这是一种痛苦。
Apple在XCode 7.3中修复了它，现在它就像一个魅力一样。它的速度超快，功能也更强大，因为它看起来有点像文件的模糊搜索：你不必真正输入方法/属性的确切开头，以便它出现在命题列表中。
折叠所有方法都有所帮助。
命令 - 交替移左箭头将做特技...
要折叠/展开的当前方法或者如果使用结构：
折：命令 - 交替 - 左箭头
展开：命令ALT键向右箭头
好视频和渐进式音乐。大声笑 – CppChase 2016-09-18 20:39:43
SourceKitService也有点笨拙处理代码中的评论和嵌入评论太慢了。
所以，如果你能负担得起的去除嵌入注释大量的斑点像这样：
/*
* comment
/*
* embedded comment
*/
*/
那肯定也能有所帮助。
注：在我的情况我的Xcode 7.3.1（7D1014）字面上阻止我输入任何字母时，文件是用嵌入的注释大约700线评论。最初我从那个.swift文件中删除了该块，并且Xcode又恢复了活力。我尝试通过删除嵌入的评论来逐个添加我的评论，但仍然比平常慢，但是如果没有嵌入的评论，它会显示更好的性能。
我在那里打字是在一个特定的类落后于同样的问题，事实证明，
/* Long multiline comments */
被拖慢打字。
我和你有同样的问题。经常Xcode告诉我“SourceKit终止，编辑暂时有限” – idmean 2014-09-20 11:01:14
是的，这也是另一个问题，我不确定它们是相关的。即使发生错误，速度也很慢。 – mllm 2014-09-20 11:08:59
我确定他们是相关的。在测试版5中，我更频繁地看到该消息，并且我发现在任何时候该建议都无效。 （当我键入一些字符，并按Esc触发建议） – idmean 2014-09-20 11:10:49