Xcode 4 - повільна продуктивність

У мене є проблема з Xcode 4, реально дуже повільно реагуючи на взаємодію користувачів, наприклад, редагування коду, прокручування областей тощо. Особливо це трапляється з масштабними проектами з великою кількістю контролерів / файлів перегляду тощо.

Я повністю витер жорсткий диск і інсталював Snow Leopard і Xcode на другий тиждень, але стабільно це загрожує знов засмучуючим часом реакції (протягом декількох днів), що значно порушує робочий процес.

Я також іноді видаляв "отримані дані" проекту через Організатор -> Проекти, і це мало ефекту.

Мені цікаво, чи є щось, що я можу зробити для поліпшення продуктивності, окрім як отримати в першу чергу інтенсивнішу версію машини.

FYI Я запускаю MacBook з процесорами Intel Core 2 Duo на частоті 2 ГГц і 4 ГБ оперативної пам’яті.

У випадку, якщо нам потрібно оновити, я також хотів би знати, чи відчувають люди цю слабку продуктивність із Xcode 4 на добре знайомих машинах (що зробить наше оновлення обладнання досить безглуздим, оскільки у MacBook є лише проблема з продуктивністю).

Якщо хтось має якісь пропозиції чи рекомендації або навіть може повідомити нам про те, як покращене обладнання впливає на продуктивність Xcode на великих деревах проектів, це може бути надзвичайно корисним, а також цінним ресурсом для інших розробників у подібній позиції.

Якщо ви очистите файл робочої області, це допоможе прискорити його.

По-перше, переконайтесь, що Xcode не відкритий. Тепер знайдіть файл свого проекту. Клацніть на ньому правою кнопкою миші та виберіть Show Package Contents.

Далі видаліть project.xcworkspace.

Відкрийте Xcode і насолоджуйтесь швидшою продуктивністю!

Завдяки: http://meachware.blogspot.com/2011/06/speed-up-xcode-4.html

Редагувати: Я отримав кілька коментарів щодо цього, зазначивши, що для деяких проектів це може спричинити проблеми. Переконайтеся, що у вас є резервна копія проекту перед виконанням цих кроків, і не забудьте перевірити і протестувати проект згодом . Будьте впевнені, що у вас ще є всі ваші виконавчі файли та схеми.

ВАЖЛИВО ОНОВЛЕННЯ: Шляхи змінені на Xcode 6 (спасибі за коментар dcc)! Я просто додав альтернативний спосіб.

Існує ще один приємний трюк, щоб зв'язати збірки, створивши операційний диск із наступним рядком коду:

diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://8475854`

Це створює образ диска в пам'яті розміром близько 4 ГБ. Але будьте обережні, потрібно мати достатньо пам’яті. Звичайно, ви можете створити менший розмір зображення розміром 2 Гб (це було б 4237927).

Потім ви скажете Xcode зберігати там отримані дані

Ви не можете сказати Xcode, щоб він безпосередньо зберігав дані iPhone Simulator, але ви можете створити папку на ramdisk і створити символічне посилання замість каталогу iPhone Simulator:

Xcode 6:

cd /Volumes/ramdisk
mkdir CoreSimulator
rm -R ~/Library/Developer/CoreSimulator
ln -s /Volumes/ramdisk/CoreSimulator ~/Library/Developer/CoreSimulator

Старіші версії Xcode:

cd /Volumes/ramdisk
mkdir iPhone\ Simulator
rm -R ~/Library/Application\ Support/iPhone\ Simulator
ln -s /Volumes/ramdisk/iPhone\ Simulator ~/Library/Application\ Support/iPhone\ Simulator

Якщо я будувати для тренажера з цим налаштуванням, він працює і працює в найкоротші терміни :)

Майте на увазі, що оперативний диск зникне при перезапуску машини, тому може бути гарною ідеєю створити сценарій або щось, що працює при запуску. І НЕ ВІДМОВАЙТЕ БІЛЬКИХ ДАНИХ ТАКІ, ЩО ВИ ХОЧЕТЕ ЗБЕРЕГАТИ !!!

ОНОВЛЕННЯ 2013-03-12:

1. Прочитайте коментар Франсіско Гарсія нижче!

2. З моїм новим MBP (що містить накопичувач SSD) мені цей метод більше не потрібен. Xcode працює як пекло :). Я сподіваюся, що це не сприймається як реклама для великого фруктового концерну, це лише звіт про досвід ...

Вимкнення "Живих" проблем у загальних налаштуваннях змінило певну різницю. Я також налаштовую схему без включення gdb для ситуацій, коли я часто повторююсь (жоден gdb не прискорює запуск зовсім небагато).

Для мене Xcode отримав величезне підвищення продуктивності після встановлення його для роботи в 32-бітному режимі (він був 64 за замовчуванням). Це майже так само швидко, як і старий Xcode 3. Ви можете переключитися на 32-бітний, клацнувши правою кнопкою миші додаток (у /Developer/Applications/XCode.app ) та вибравши Отримати інформацію та встановити прапорець Відкрити в 32-бітному режимі .

Xcode 4.2, 4.3:

Основні проблеми з файловим індексатором (той самий код, який працює під прожектором, який вже протягом багатьох років баггі? Мабуть).

Вимкніть все несуттєве, що пов'язано з "переглядом" файлів:

1. Швидка довідка (зверніть увагу: ніколи не натискайте на вкладку Швидка допомога! Навіть приховування Асистента все ще змушує запустити код! Перехід на іншу вкладку перед переходом до нового файлу ...)
2. Управління SCM (SVN, Git і т. Д. - підтримка git Xcode все ще є невеликою помилкою (може пошкодити проекти), і вони втратили підтримку SVN, тому вам не слід користуватися нею!)
3. спробуйте видалити папку робочої області (відповідно до прийнятої відповіді), але тільки якщо вона є великою на диску
4. ... все, що ви можете знайти, пов’язані зі статусом окремих файлів

Xcode 4.4, 4.5:

Ці версії мають значну протікання пам’яті, пошкоджений індексатор файлів (але краще, ніж 4,2 та 4,3), і, можливо, проблема з приватним файлом підкачки.

Врешті-решт, відключивши / увімкнувши пробільний простір ( як відключити чи включити заміну в mac os x ), а також використовувати звичайні жорсткі диски на декількох машинах та запустивши експерименти на машинах з 2 ГБ оперативної пам’яті до 16 ГБ оперативної пам’яті, я виявив, що Xcode здається, працює власний простір swap, незалежний від swap OS X (!).

(це може бути помилкою - можливо, є додаткова форма заміни OS X, про яку я не знаю, - але файли підкачки системи не збільшувались або зменшувались, а на диску на деяких машинах простір на диску гігабайти)

Помічено:

1. Xcode 4.4 / 4.5 випадковим чином візьме всю оперативну пам’ять у вашій системі (10 ГБ за крихітний проект), так що решта системи перемели до зупинки, застрягнувши в очікуванні заміни диска

   1. ХОРОШИЙ: на комп'ютерах із SSD дисками ви не знаєте, що це сталося
   2. ПЕРШИЙ: ... навіть якщо це, можливо, пошкодить ваш жорсткий диск (SSD не любить лупати записи)

2. Xcode заграє доступ до жорсткого диска, щоб він міг здійснювати (порушений) внутрішній індексацію файлів. Коли системна пам'ять стає низькою, а OS X потребує заміни ... вона затримується в очікуванні, коли Xcode індексує файли ... і Xcode займає більше пам'яті, поки він чекає ... і: BOOM! на менших системах ОС X з часом висить

3. Xcode не потребує місця для обміну OS X

Остання дуже цікава. Якщо у вас багато пам’яті (наприклад, 16 ГБ), спробуйте назавжди вимкнути місце для заміни. Xcode працює швидше, оскільки OS X Lion має деякі помилки в управлінні пам’яттю, де він обмінюється, навіть коли цього не потрібно .

Якщо xcode сповільнюється раптово, він змінюється внутрішньо, і тоді ви можете просто вбити і перезапустити його.

(якщо у вас SSD, єдиний спосіб дізнатися, чи почалася його заміна - це почекати, коли він "повільніше". В іншому випадку, ви знаєте, як тільки почуєте HD-треш: більше не існує системи swapfile, тому Єдина можлива причина - Xcode)

Ви можете безпечно відключити своп, навіть якщо у вас є 2 Гб оперативної пам’яті (у мене була лише одна аварія ОС X на місяць, коли я намагався це, запускав це таким чином протягом року), але це перешкодить вам робити високоякісні відео / графічні роботи з файлами яким для запуску потрібні багатогігабайти. Не соромтеся спробувати це кілька тижнів і подивіться, що вийде.

Але ... перезапуск Xcode кожного разу, коли він сповільнює, творить чудеса. На машинах з меншою пам’яттю оперативної пам’яті приватний свопфайл Xcode, здається, негайно видаляється, коли ви закриваєтесь (схоже, це не відбувається на машинах з великою кількістю оперативної пам’яті)

Жодна з цих відповідей в моєму випадку дійсно не покращила продуктивність (з часом Xcode 4.1 став навряд чи придатним для використання. Лише вийшов з нього і допоміг).

Однак я щойно з’ясував, що якщо я продовжую закривати всі свої документи (control-command-W), то, здається, залишається швидким. Xcode автоматично зберігає всі документи, які ви якось натискаєте на пам'ять, і ви можете переходити між ними за допомогою клавіші управління-команда вліво / вправо. Якщо ви випадково відкриєте занадто багато (особливо вікон IB), воно повзає. Просто закривання всіх відкритих документів раз у раз зменшується, не потребуючи повного перезавантаження.

Наступний допис від @lukasz трохи допоміг, особливо його пункт № 8 у своїй відповіді (Закрита панель утиліти та швидка панель довідки)

Xcode 4 став надзвичайно повільним і вбиває мій жорсткий диск

Усі, хто стикається з цими проблемами, повинні спробувати Xcode 4.1 на Mac OS X Lion. Я здивований тим, наскільки швидше і чуйніше це на одному і тому ж апаратному забезпеченні (Macbook Pro 2,66 ГГц Core 2 Duo з 4 ГБ ОЗУ тут).

Я думаю, що вони виправили тонни помилок продуктивності з цим випуском.

Запустіть інструменти за допомогою шаблону профілю часу та додайте його до запущеного Xcode (або clang, llvm тощо), якщо проблема виникає під час збирання). Ви повинні мати можливість побачити проблему досить швидко. Я бачив дуже різні причини на різних машинах. Контроль версій часто є винуватцем.

Я стикаюся з тими ж проблемами. Вони були частково виправлені, оскільки бета-версії все ще зберігаються. Здається, що Xcode внутрішньо отримав один або кілька витоків, які плавають у вашій пам'яті. Ви можете дуже добре переглядати цю вишукану "функцію", використовуючи інтегрований Interface-Builder. Два можливих рішення під молитвою та заповненням повідомлень про помилки для яблук:

1. Не використовуйте внутрішній Builder, замість цього запустіть зовнішню програму.
2. Час від часу виходити з Xcode, це повинно звільнити пам'ять, яка просочилася.

Я спробував майже все, що було запропоновано в цій темі, та [численні] інші, і єдине, що працювало для мене, - це «відключити» підрив для проекту. Ось хитра частина - ТІЛЬКИ спосіб, яким я міг "відключити" вбудований плагін SVN, полягав у тому, щоб скасувати мій / etc / hosts файл із фальшивою IP-адресою, що фактично призводить до відмови всього доступу до SVN.

Я спробував видалити / перейменувати IDESubversion.ideplugin в / Developer / Library / Xcode / PrivatePlugIns, але Xcode 4.2.1 відключає і відмовляється починати.

Я намагався видаляти свої сховища SVN з Xcode кожен раз, коли я перезавантажував Xcode, але Xcode виходить з ладу протягом декількох хвилин.

Я спробував вимкнути "Віддалений статус" через Файл-> Контроль джерела-> Сховати віддалений статус (нічого не зробив для мене).

Тепер, коли я встановив своє ім'я хоста SVN у 1.2.3.4 у файлі хостів, Xcode чудово працює і не показує SBBOD майже кожного разу, коли я переключаюся між файлами.

$ grep 1.2.3.4 /etc/hosts
1.2.3.4 svn.myhost.com

Потім, коли я дуже хочу зайнятися контролем версій, мені доведеться скасувати файл хостів і використовувати cmd-рядок svn.

Ви можете уникнути індексації Xcode. Це дозволить покращити продуктивність пам'яті вашої системи, але також запобіжить функціям IDE, таких як автодоповнення і перейти до визначення.

$ defaults write com.apple.dt.XCode IDEIndexDisable 1

Якщо ви маєте низьку продуктивність під час зміни файлу .xib за допомогою конструктора інтерфейсу / редактора інтерфейсу, перейдіть у розділ File Inspector для .xib та відключіть автоматичне розміщення . Внесіть зміни до .xib, а потім, як завершальний крок, знову ввімкніть автоматичну компоновку та додайте або відрегулюйте обмеження.

Нарешті я змусив свій Xcode працювати нормально, вимкнувши функцію git.

Я вирішив свою проблему, відключивши знімки, як описано тут:

Редагування розкадровки в Xcode 5 відбувається дуже повільно

У моєму випадку це було використання оперативної пам’яті.

Спробуйте вбити кілька вкладок Chrome або рідко використовуваних додатків.

Я знайшов хитрість, щоб прискорити продуктивність компіляції XCode 4: Коли ви запускаєте або компілюєте або виконуєте будь-яку іншу обробку в Xcode і вона зупиняє відкритий активний монітор, виберіть процес Xcode і натисніть на зразок процесу. Це зробить процес відклеювання і запуститься знову як звичайне, що дозволить створити додаток у розумний час.