Xcode 6 с быстрым супер медленным типом и автозаполнением

Ответ 1

• Выйти из Xcode и перезагрузить Mac не требуются, но предпочтительнее.
• Удалить содержимое папки ~/Library/Developer/Xcode/DerivedData​​li >
• Удалить контент ~/Library/Caches/com.apple.dt.Xcode

Это временное решение, но работает значительно.

Ниже script с помощью приложения script Editor.

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

В качестве альтернативы вы можете создать псевдоним для своего терминала следующим образом:

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

Вы можете добавить это в свой ~/.bash_profile, а затем введите xcodeclean в командной строке каждый раз, когда вы хотите очистить эти две папки.

Ответ 2

Я также испытал 100% + CPU при наборе некоторого "простого" кода. Некоторые небольшие трюки, чтобы ускорить быстрый парсер, так как вы структурируете свой код.

Не используйте континент "+" в строках. Для меня это очень быстро вызывает медленность. Каждый новый "+" выводит парсер на обход, и он должен повторно обрабатывать код каждый раз, когда вы добавляете новый char где-то в свой кузов.

Вместо:

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

Используйте синтаксис шаблона, который кажется более эффективным для синтаксического анализа:

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

Таким образом, я практически не замечаю предела в strlen с встроенными vars "\ (*)".

Если у вас есть расчеты, которые используют +/* - затем разбивают их на более мелкие части.

Вместо:

var result = pi * 2 * radius 

использовать:

var result  = pi * 2
    result *= radius

Он может выглядеть менее эффективным, но быстрый парсер намного быстрее. Некоторые формулы не будут компилироваться, если они имеют много операций, даже если они математически правильны.

Если у вас есть сложные вычисления, то положите их в func. Таким образом, синтаксический анализатор может разобрать его один раз и не переписывать его каждый раз, когда вы что-то изменяете в своем теле функции.

Потому что, если у вас есть расчет в вашем теле функции, то как-то быстрый парсер проверяет его каждый раз, если типы, синтаксис и т.д. все еще верны. Если строка изменяется над расчетом, то некоторые вары внутри вашего расчета/формулы могут быть изменены. Если вы поместите его во внешнюю функцию, он будет проверен один раз, и быстро будет рад, что он будет правильным и не будет повторно обрабатывать его постоянно, что приводит к высокому использованию ЦП.

Таким образом, я получил от 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 )

но если я поместил его в 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 и XCode 6.1 по-прежнему очень ошибочны, но если вы будете следовать этим простым трюкам, код редактирования снова станет приемлемым. Я предпочитаю очень быстро, поскольку он избавляется от файлов .h и использует гораздо более чистый синтаксис. Существует еще много типов, требующих типа "myVar как AnyObject", но это меньшее зло по сравнению с сложной структурой проекта и синтаксисом objective-c.

Еще один опыт, я попробовал SpriteKit, который очень полезен, но его довольно эффективный, если вам не нужна постоянная перерисовка со скоростью 60 кадров в секунду. Использование старых CALayers намного лучше для CPU, если ваши "спрайты" не так часто меняются. Если вы не меняете .contents слоев, тогда CPU в основном бездействует, но если у вас есть приложение SpriteKit, работающее в фоновом режиме, то видеозапись в других приложениях может начать заикаться из-за ограниченного цикла обновления в 60fps.

Иногда xcode показывает нечетные ошибки при компиляции, затем помогает перейти в меню "Продукт > Очистить" и скомпилировать его снова, кажется, является ошибкой реализации кэша.

Еще один отличный способ улучшить синтаксический анализ, когда xcode застрял с вашим кодом, упоминается в другом postoverflow post здесь. В основном вы копируете все содержимое из вашего .swift файла во внешний редактор, а затем через функцию копируете его и видите, где находится ваше узкое место. Это действительно помогло мне снова получить xcode на разумной скорости, после того, как мой проект сошел с ума со 100% -ым процессором. при копировании кода обратно, вы можете реорганизовать его и попытаться сохранить свои функциональные тела короткими, а функции/формуляры/выражения простыми (или разделить на несколько строк).

Ответ 3

Автокомпьютер сломан с Xcode 4. Пока Apple не решит исправить эту ошибку 2 года, единственным решением, к сожалению, является завершение кода ВЫКЛ по предпочтениям XCode (первый вариант рисунка ниже).

Вы можете продолжить пользоваться завершением вручную, набрав CTRL space или ESC, когда вам это нужно.

Это единственное решение, которое работает каждый раз для 100% случаев.

Еще одна вещь, которую я недавно обнаружил: если вы используете плагины на Xcode, не делайте этого. Удалите их все. Они делают проблему хуже.

Ответ 4

Используете ли вы Spotify? Я установил Yosemite GM с Xcode 6.1 GM на iMac в середине 2009 года (2.66Ghz) с той же проблемой. Я обнаружил, что процесс под названием "SpotifyWebHelper" всегда отмечен красным как не отвечающий, поэтому я отключил опцию "начать с Интернета" в и теперь Xcode выглядит значительно лучше.

Ответ 5

У меня были те же проблемы даже в Xcode 6.3

• супер медленные автозаполнения
• супер медленная индексация
• Огромное использование процессора быстрым и SourceKitService
• Огромное использование памяти SourceKitService

Все это происходило даже в относительно небольшом проекте. Я пробовал все исправления, которые мог найти:

• удаление ~/Library/Разработчик/Xcode/DerivedData/*
• удаление ~/Library/Caches/com.apple.dt.Xcode/*
• удалить все "+" Строка, объединяющую код
• удалены все подозрительные словарные объявления

Ничего из этого не помогло в моем проекте.

Что на самом деле решило мою проблему:

• размещение каждого конца каждого класса в собственном файле
• размещение каждого расширения в собственном файле (Class + ExtName.swift)
• размещение "вне класса быстрых методов" в собственном файле

Теперь у меня почти нет использования ЦП, низкого использования памяти и прилично быстрых завершений.

Ответ 6

Как правило, перемещение папки кэша (DerivedData) на SSD-диск (в частности, в моем случае - внешнее хранилище, связанное с выходом thunderbolt) значительно улучшило мою производительность Xcode. Время компиляции и общее удивление вокруг приложения составляет около 10 раз быстрее. Также переместил всю папку git на SSD, что значительно улучшило производительность git.

Ответ 7

Это была боль до XCode 7.2.

Apple исправила его в XCode 7.3, и теперь он работает как шарм. Он супер быстрый и гораздо более мощный, поскольку он, похоже, немного похож на нечеткий поиск файлов: вам не нужно на самом деле вводить точное начало метода/свойства, чтобы он отображался в списке предложений.

Ответ 8

Свертывание всех методов помогает немного.

команда-alt-shift-left стрелка сделает трюк...

Чтобы свернуть/развернуть текущие методы или использовать структуры:

Fold: команда-alt-left arrow

Unfold: command-alt-right arrow

Ответ 9

Я узнал, что обычно это происходит, когда вы:

• имеют длинные выражения в одном выражении (см. этот ответ)
• смешивать несколько настраиваемых операторов в одном выражении

Второй случай, похоже, исправлен в одном из последних выпусков xcode. Пример: я определил 2 пользовательских оператора < & → < || > и использовалс в выражении, таком как a <&&> b <&&> c <||> d. Разделение на несколько строк решает проблему:

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

Я надеюсь, что ваши дела охвачены одним из двух выше... Пожалуйста, напишите комментарий в любом случае

Ответ 10

SourceKitService также неловко разбирается с комментариями в коде и встроенными комментариями замедляет работу.

поэтому, если вы можете позволить себе удалить массивный кусок встроенных комментариев, например:

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

которые могут определенно помочь.

ПРИМЕЧАНИЕ: в моем случае мой Xcode 7.3.1 (7D1014) был буквально заблокирован, я набрал любую букву, когда в файле было около 700 строк комментария со встроенными комментариями. сначала я удалил этот блок из этого файла .swift, и Xcode снова стал живым. Я попытался добавить свои комментарии назад частично, удалив встроенные комментарии, но все же медленнее, чем обычно, но показал значительно лучшую производительность, если не было встроенных комментариев.

Ответ 11

У меня была такая же проблема, когда печатание было отстающим в определенном классе и оказалось, что

/* Long multiline comments */

замедлял ввод текста.