Я также испытал 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
Это может показаться менее эффективным, но быстрый парсер в этом случае работает намного быстрее. Некоторые формулы не компилируются при большом количестве операций, даже если они математически верны.
Если у вас есть сложные вычисления, поместите их в func. Таким образом, синтаксический анализатор может проанализировать его один раз, и ему не придется повторно анализировать его каждый раз, когда вы что-то меняете в теле функции.
Потому что, если у вас есть вычисление в теле вашей функции, то каким-то образом быстрый синтаксический анализатор проверяет его каждый раз, если типы, синтаксис и т. Д. Все еще верны. Если строка над расчетом изменится, то некоторые переменные внутри вашего расчета / формулы могли измениться. Если вы поместите его во внешнюю функцию, тогда он будет проверен один раз, и swift будет счастлив, что он будет правильным и не будет повторно анализировать его постоянно, что вызывает высокую загрузку ЦП.
Таким образом, я получил от 100% при каждом нажатии клавиши до низкой загрузки процессора при наборе текста. Например, эти 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», но это меньшее зло по сравнению со сложной структурой и синтаксисом проекта objective-c.
Еще один опыт: я попробовал SpriteKit, который приятно использовать, но он довольно неэффективен, если вам не нужна постоянная перерисовка со скоростью 60 кадров в секунду. Использование старых CALayers намного лучше для ЦП, если ваши «спрайты» не меняются так часто. Если вы не измените содержимое слоев, то ЦП в основном простаивает, но если у вас есть приложение SpriteKit, работающее в фоновом режиме, воспроизведение видео в других приложениях может начать прерываться из-за жестко ограниченного цикла обновления 60 кадров в секунду.
Иногда xcode показывает странные ошибки при компиляции, тогда это помогает зайти в меню «Продукт> Очистить» и скомпилировать его снова, что кажется ошибочной реализацией кеша.
Еще один отличный способ улучшить синтаксический анализ, когда xcode застревает в вашем коде, упоминается в другом сообщении stackoverflow здесь . По сути, вы копируете все содержимое из файла .swift во внешний редактор, а затем по функциям копируете его обратно и смотрите, где находится ваше узкое место. Это на самом деле помогло мне снова получить нормальную скорость xcode после того, как мой проект сошёл с ума со 100% CPU. копируя свой код обратно, вы можете провести его рефакторинг и постараться, чтобы ваши тела функций были короткими, а функции / формуляры / выражения простыми (или разбивались на несколько строк).
