blocks|key|2940050|text|我发现这通常发生在你：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2940051|多个自定义运算符在单个语句中包含长表达式(请参见this+answer)|offset|length|2940052|mix+multiple+|unordered-list-item|2940053|
|2940054|+operators+in++single+|2940055|2940056|2940057|2940058|第二种情况似乎在最新的xcode版本中得到了修复。示例:我定义了两个自定义运算符<&&>和<%7C%7C>，并在类似a+<&&>+b+<&&>+c+<%7C%7C>+d的表达式中使用。拆分成多行解决了问题：|style|CODE|2940059|let+r1+=+a+<&&>+b
let+r2+=+r1+<&&>+c
let+r3+=+r2+<%7C%7C>+d|code-block|syntax|javascript|2940060|我希望你的案例包含在上面的两个案例中的一个...无论哪种情况，请发表评论|2940061|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/25813625/148357^0|0|O|B|0|0|0|0|0|0|0|0|1I|M|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]]|A|$]]|$1|F|3|G|5|H|7|1D|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1E|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|1F|8|@]|9|@]|A|$]]|$1|M|3|-4|5|H|7|1G|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1J|8|@$D|1K|E|1L|R|S]]|9|@]|A|$]]|$1|T|3|U|5|V|7|1M|8|@]|9|@]|A|$W|X]]|$1|Y|3|Z|5|6|7|1N|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

I found out that usually happens when you:

<ul>
<li>have long expressions in a single statement (see <a href="https://stackoverflow.com/a/25813625/148357">this answer</a>)</li>
<li>mix multiple custom operators in a single expression</li>
</ul>

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

<pre><code>let r1 = a &lt;&amp;&amp;&gt; b
let r2 = r1 &lt;&amp;&amp;&gt; c
let r3 = r2 &lt;||&gt; d
</code></pre>

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

blocks|key|146410|text|你在使用Spotify吗？我在2009年年中(2.66+the+)的iMac+mid+(2.66+the+)上安装了Yosemite+GM和Xcode6.1GM，也有同样的问题。我发现一个叫"SpotifyWebHelper“的进程总是被标记为红色，没有响应，所以我在spotify中禁用了”从网络启动“选项，现在Xcode似乎运行得更好了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|146411|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|2940130|text|在输入一些“简单”代码时，我也体验到了100%25%2B的CPU。一些小技巧，让快速解析器更快，通过你的代码结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2940131|不要在字符串中使用"%2B“连接符。对我来说，这很快就会触发速度变慢。每一个新的"%2B“都会使解析器爬行，每当你在函数体的某个地方添加一个新字符时，解析器都必须重新解析代码。|2940132|而不是：|2940133|var+str+=+"This"+%2B+String(myArray.count)+%2B+"+is+"+%2B+String(someVar)|code-block|syntax|javascript|2940134|使用模板语法，它看起来在swift中解析更有效：|2940135|var+str+=+"This+\(myArray.count)+is+\(someVar)"|2940136|这样，我基本上注意到在strlen中没有内联变量"(*)“的限制。|2940137|如果你有计算，使用%2B/*-，那么把它们分成更小的部分。|2940138|2940139|var+result+=+pi+*+2+*+radius+|2940140|使用：|2940141|var+result++=+pi+*+2
++++result+*=+radius|2940142|它可能看起来效率较低，但这种方式的快速解析器要快得多。一些公式无法编译，即使它们在数学上是正确的，如果它们必须进行许多操作。|2940143|如果你有一些复杂的计算，那么把它放在一个函数中。这样，解析器就可以解析它一次，而不必在每次更改函数体中的内容时都重新解析它。|2940144|因为如果你的函数体中有一个计算，那么swift解析器每次都会检查它，看看类型、语法等是否仍然正确。如果计算结果上面的某一行发生了变化，那么计算/公式中的某些变量可能已经发生了变化。如果你把它放在一个外部函数中，那么它将被验证一次，swift很高兴它是正确的，并且不会不断地重新解析它，这是导致高CPU使用率的原因。|2940145|通过这种方式，我可以从每次按键时的100%25减少到键入时的低CPU。例如，将这3行代码内联到您的函数体中，就可以使swiftparser爬行。|2940146|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+)|2940147|但是如果我把它放在一个函数中，稍后再调用它，swiftparser会快得多。|2940148|//+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)+
}|2940149|Swift和XCode+6.1仍然有很多错误，但是如果你遵循这些简单的技巧，编辑代码就会变得可以接受。我更喜欢swift，因为它去掉了.h文件，使用了更干净的语法。仍然需要许多类型转换，比如"myVar+as+AnyObject“，但与复杂的objective-c项目结构和语法相比，这是较小的缺点。|2940150|还有另一种体验，我尝试了SpriteKit，它使用起来很有趣，但如果你不需要以60fps的速度不断重新绘制，它的效率就会很低。如果你的“精灵”不经常改变，那么使用旧的CALayers会更好。如果你不改变图层的.contents，那么CPU基本上是空闲的，但如果你有一个在后台运行的SpriteKit应用程序，那么其他应用程序中的视频播放可能会因为硬性限制的60fps更新循环而开始卡顿。|2940151|有时xcode在编译时会显示奇怪的错误，然后它有助于进入菜单"Product+>+Clean“并重新编译它，这似乎是缓存的一个buggy实现。|2940152|当xcode被代码卡住时，另一个改进解析的好方法在另一个stackoverflow+post+here中提到。基本上，您将.swift文件中的所有内容复制到外部编辑器中，然后逐个函数地将其复制回来，并查看瓶颈所在。这实际上帮助我让xcode再次达到一个合理的速度，在我的项目在100%25的CPU下变得疯狂之后。当复制你的代码时，你可以重构它，并尽量保持你的函数体简短，函数/公式/表达式简单(或者拆分成几行)。|offset|length|2940153|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/24442837/4158700^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1B|4|0|0^^$0|@$1|2|3|4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1X|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1Y|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|20|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|21|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|22|8|@]|9|@]|A|$]]|$1|S|3|E|5|6|7|23|8|@]|9|@]|A|$]]|$1|T|3|U|5|H|7|24|8|@]|9|@]|A|$I|J]]|$1|V|3|W|5|6|7|25|8|@]|9|@]|A|$]]|$1|X|3|Y|5|H|7|26|8|@]|9|@]|A|$I|J]]|$1|Z|3|10|5|6|7|27|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|28|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|29|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|2A|8|@]|9|@]|A|$]]|$1|17|3|18|5|H|7|2B|8|@]|9|@]|A|$I|J]]|$1|19|3|1A|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|H|7|2D|8|@]|9|@]|A|$I|J]]|$1|1D|3|1E|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2F|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2H|8|@]|9|@$1L|2I|1M|2J|1|2K]]|A|$]]|$1|1N|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|1O|$1P|$5|1Q|1R|1S|A|$1T|1U]]]]

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. 

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:

<pre><code>var str = "This" + String(myArray.count) + " is " + String(someVar)
</code></pre>

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

<pre><code>var str = "This \(myArray.count) is \(someVar)"
</code></pre>

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

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

Instead of:

<pre><code>var result = pi * 2 * radius 
</code></pre>

use: 

<pre><code>var result = pi * 2
 result *= radius
</code></pre>

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. 

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. 

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. 

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. 

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

println ( spaces )
</code></pre>

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

<pre><code>// 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&lt;*&gt; 
// 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() -&gt; Array&lt;Dictionary&lt;String, AnyObject&gt;&gt; {
 let fullPath = "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"

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

 return spaces
}

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

 let spaces = self.getSpacesDataFromPlist()
 println( spaces) 
}
</code></pre>

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. 

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.

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. 

Another great way to improve parsing when xcode gets stuck with your code is mentioned in another stackoverflow post <a href="https://stackoverflow.com/a/24442837/4158700">here</a>. 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).

blocks|key|2727774|text|不需要退出Xcode并重新启动Mac，但可以在~/Library/Developer/Xcode/DerivedData|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2727775|Delete+content|unordered-list-item|2727776|+~/Library/Caches/com.apple.dt.Xcode|2727777|文件夹的|2727778|+content中找到它|offset|length|style|BOLD|2727779|2727780|2727781|这是一个暂时的解决方案，但效果很好。|2727782|下面的脚本使用脚本编辑器应用程序。|2727783|tell+application+"Terminal"
++++do+script+"rm+-frd+~/Library/Developer/Xcode/DerivedData/*"
++++do+script+"rm+-frd+~/Library/Caches/com.apple.dt.Xcode/*"
end+tell|code-block|syntax|javascript|2727784|或者，您可以为您的终端创建别名，如下所示：|2727785|alias+xcodeclean="rm+-frd+~/Library/Developer/Xcode/DerivedData/*+&&+rm+-frd+~/Library/Caches/com.apple.dt.Xcode/*"|2727786|您可以将其添加到~/.bash_profile中，然后在每次要清除这两个文件夹时在命令行上键入xcodeclean。|CODE|2727787|entityMap^0|0|0|0|0|1|7|0|0|0|0|0|0|0|0|8|F|1B|A|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|19|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|1A|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1B|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1C|8|@$K|1D|L|1E|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1H|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1I|8|@]|9|@]|A|$]]|$1|U|3|V|5|W|7|1J|8|@]|9|@]|A|$X|Y]]|$1|Z|3|10|5|6|7|1K|8|@]|9|@]|A|$]]|$1|11|3|12|5|W|7|1L|8|@]|9|@]|A|$X|Y]]|$1|13|3|14|5|6|7|1M|8|@$K|1N|L|1O|M|15]|$K|1P|L|1Q|M|15]]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|17|$]]

<ul>
<li>Quit Xcode and restart the Mac are not required but preferred.</li>
<li>Delete the content of the folder
~/Library/Developer/Xcode/DerivedData</li>
<li>Delete the content ~/Library/Caches/com.apple.dt.Xcode</li>
</ul>

This is a temporally solution, but works greatly.

Below the script using Script Editor app.

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

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

<pre><code>alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* &amp;&amp; rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
</code></pre>

You can add that to your <code>~/.bash_profile</code> and then type <code>xcodeclean</code> on the command line every time you would like to clear those two folders.

blocks|key|2727861|text|在苹果决定修复这个两年前的bug之前，不幸的是，唯一的解决方案是在Xcode的首选项上关闭代码完成(下面图片中的第一个选项)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2727862|您可以继续通过在需要时输入CTRL+space或ESC来手动完成。|CODE|2727863|这是唯一一种对100%25的情况都有效的解决方案。|2727864|​|2727865|📷|atomic|2727866|2727867|我最近发现的另一件事是:如果你在Xcode上使用插件，不要使用，全部删除。它们会让问题变得更糟。|2727868|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/58e91e5b5017a28fac05b26b25a74573.png|imageAlt^0|1D|E|0|0|X|D|A|O|3|0|0|N|0|0|1|0|0|1|0|1|0|0|0|1|0|0|1C|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|H]|$9|19|A|1A|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|M|3|N|5|O|7|1H|8|@$9|1I|A|1J|B|C]]|D|@$9|1K|A|1L|1|1M]]|E|$]]|$1|P|3|L|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]]|T|$U|$5|V|W|X|E|$Y|Z|10|-4]]]]

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 OFF on XCode's preferences (first option of the pic below).

You can continue to enjoy completion manually by typing <code>CTRL space</code> or <code>ESC</code> when you need it.

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

<img src="https://i.stack.imgur.com/Y0FDf.png" alt="enter image description here">

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

blocks|key|150440|text|我在Xcode6.3中也遇到了同样的问题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|150441|swift的indexing|150442|enormous+CPU使用率和SourceKitService|unordered-list-item|150443|
的SourceKitService|150444|enormous内存使用率分别为SourceKitService|150445|
和|150446|超慢CPU使用率|150447|150448|所有这一切即使在相对较小的项目中也会发生。我尝试了我能找到的所有修复：|150449|150450|删除从代码中组合的所有"%2B“字符串|150451|删除所有可疑的字典声明|150452|150453|这些对我的项目都没有实际的帮助。|150454|真正解决了我的问题的是：|150455|类外快速方法将每个类都放在自己的文件中，每个扩展名都放在自己的文件中，“(Class%2BExtName.swift)|150456|placing+of+|150457|”放在自己的文件中|150458|150459|150460|现在，我的CPU使用率几乎为零，内存使用率很低，完成速度也相当快。|150461|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1E|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1F|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1G|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1H|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1I|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|1J|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1L|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1N|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|1O|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1R|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1S|8|@]|9|@]|A|$]]|$1|13|3|14|5|F|7|1T|8|@]|9|@]|A|$]]|$1|15|3|16|5|F|7|1U|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|1X|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|1C|$]]

I had the same issues even in Xcode 6.3 

<ul>
<li>super slow autocompletions</li>
<li>super slow indexing</li>
<li>enormous CPU usage by swift and SourceKitService</li>
<li>enormous Memory usage by SourceKitService</li>
</ul>

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

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

None of these actually helped in my project.

What actually solved my problem was:

<ul>
<li>placing each end every class in its own file</li>
<li>placing each and every extension in its own file (Class+ExtName.swift)</li>
<li>placing "out of class swift methods" in its own file</li>
</ul>

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

blocks|key|2727954|text|通常，将缓存文件夹(DerivedData)移动到SSD驱动器(特别是在我的例子中-连接到thunderbolt+exit的外部存储)可以极大地提高我的Xcode性能。编译时间和对应用程序的总体了解大约快了10倍。还将整个git文件夹移动到了SSD，这极大地提高了git的性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2727955|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|146517|text|在XCode+7.2之前，这是一件痛苦的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|146518|苹果在XCode+7.3中修复了这个问题，现在它的效果非常好。它非常快，而且功能更强大，因为它看起来有点像文件的模糊搜索:你不需要实际输入方法/属性的确切开头，它就会出现在命题列表中。|146519|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It was a pain until 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.

blocks|key|147885|text|折叠所有方法会有一点帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|147886|command-alt-shift-left箭头组合键可以完成此操作...|147887|要折叠/展开当前方法或结构，请执行以下操作：|147888|折叠:+command-alt-left箭头|147889|展开:command-alt-右箭头|147890|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Collapsing all methods helps a little.

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

To fold/unfold current methods or if structures use:

Fold: command-alt-left arrow

Unfold: command-alt-right arrow

blocks|key|147903|text|SourceKitService在处理代码中的注释时也有点笨拙，而embedded+comments也减慢了它的速度。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|147904|因此，如果你有能力删除像这样的大量嵌入注释：|147905|/*
+*+comment+
++++/*
+++++*+embedded+comment
+++++*/
+*/|code-block|syntax|javascript|147906|这当然也是有帮助的。|147907|147908|注意：在我的例子中是我的Xcode7.3.1+(7D1014)，当文件有大约700行带有嵌入注释的注释时，我键入任何字母都会被阻止。最初，我从该.swift文件中删除了该块，Xcode再次变得活跃起来。我试着通过删除嵌入的注释来一部分地添加我的注释，它仍然比平时慢，但如果没有嵌入的注释，它的性能要好得多。|147909|entityMap^0|0|G|X|H|0|0|0|0|0|0|3|20|6|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|Z|8|@]|E|@]|F|$]]|$1|I|3|J|5|K|7|10|8|@]|E|@]|F|$L|M]]|$1|N|3|O|5|6|7|11|8|@]|E|@]|F|$]]|$1|P|3|-4|5|6|7|12|8|@]|E|@]|F|$]]|$1|Q|3|R|5|6|7|13|8|@$9|14|A|15|B|D]|$9|16|A|17|B|C]]|E|@]|F|$]]|$1|S|3|-4|5|6|7|18|8|@]|E|@]|F|$]]]|T|$]]

<code>SourceKitService</code> is also kinda clumsy to deal with comments in the code and the embedded comments slow it down too.

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

<pre><code>/*
 * comment 
 /*
 * embedded comment
 */
 */
</code></pre>

that can definitely help as well.

<hr>

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 <code>.swift</code> file 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.

blocks|key|149249|text|我也遇到过同样的问题，在某个特定的类中，输入速度很慢，结果发现|type|unstyled|depth|inlineStyleRanges|entityRanges|data|149250|/*+Long++multiline++comments+*/|offset|length|style|CODE|149251|减慢了打字速度。|149252|entityMap^0|0|0|V|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I had the same issue where typing was lagging in a particular class and turns out that 

<code>/*
Long 
multiline 
comments
*/</code> 

was slowing down the typing.

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

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

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

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

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.

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

Thoughts / tips?

Xcode 6 with Swift super slow typing and autocompletion

Objective-C

Swift

Xcode

当你输入你的代码时，特别是在自动完成的情况下，Swift的Xcode6 (6.0.1)似乎是超级慢的？一个普通的Objective-C类，即使在Swift项目中，工作起来几乎和以前一样，所以是Swift杀死了它。有没有其他人经历过同样的不便？你知道如何提高性能吗？我尝试过一些设置，但没有成功。我当然也尝试过重启Xcod...

问Xcode 6具有Swift超慢打字和自动完成功能
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Xcode 6具有Swift超慢打字和自动完成功能EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Xcode 6具有Swift超慢打字和自动完成功能
EN