Xcode 4 - yavaş performans

Xcode 4'ün kullanıcı etkileşimlerine gerçekten çok yavaş yanıt vermesiyle ilgili bir sorun yaşıyorum, örneğin kodu düzenleme, alanları kaydırma vb. Bu özellikle çok sayıda denetleyici / görüntüleme dosyası içeren daha büyük ölçekli projelerde oluyor.

Sabit diski tamamen sildim ve geçen hafta Snow Leopard ve Xcode'u yeniden yükledim, ancak iş akışını önemli ölçüde kesintiye uğratan tekrar (birkaç gün içinde) sinir bozucu bir yanıt süresine istikrarlı bir şekilde dayandım.

Ayrıca zaman zaman projenin "türetilmiş verilerini" Organizatör -> Projeler aracılığıyla kaldırdım ve bunun çok az etkisi oldu.

İlk etapta daha yüksek özellikli bir makine elde etmek dışında performansı artırmak için yapabileceğim bir şey olup olmadığını merak ediyorum.

Bilginize 2GHz ve 4GB RAM'de Intel Core 2 Duo işlemcilerle MacBook çalıştırıyorum.

Yükseltmemiz gerekirse, insanların iyi teknik özelliklere sahip makinelerde Xcode 4'ten bu düşük performansı yaşayıp yaşamadıklarını da bilmek isterim (bu, MacBook'ta herhangi bir performans sorunu olan tek Xcode olduğu için donanım yükseltmemizi oldukça anlamsız kılar).

Herhangi birinin herhangi bir önerisi veya tavsiyesi varsa veya hatta iyileştirilmiş donanımın Xcode'un performansını daha büyük proje ağaçlarında nasıl etkilediğini bize bildirebilirse, bu son derece yararlı ve aynı zamanda benzer konumdaki diğer geliştiriciler için değerli bir kaynak olacaktır.

Çalışma alanı dosyasını temizlerseniz, hızlandırmaya yardımcı olur.

Öncelikle, Xcode'un açık olmadığından emin olun. Şimdi proje dosyanızı bulun. Üzerine sağ tıklayın ve seçin Show Package Contents.

Ardından silin project.xcworkspace.

Xcode'u açın ve daha hızlı performansın tadını çıkarın!

Teşekkürler: http://meachware.blogspot.com/2011/06/speed-up-xcode-4.html

Düzenleme: Bununla ilgili birkaç yorum aldım ve bazı projeler için bunun sorunlara neden olabileceğini belirttim. Bu adımları gerçekleştirmeden önce projenizin yedeğini aldığınızdan emin olun ve daha sonra projenizi kontrol etmeyi ve test etmeyi unutmayın . Hala tüm çalıştırılabilir dosyalarınıza ve düzenlerinize sahip olduğunuzdan emin olun.

ÖNEMLİ GÜNCELLEME: Xcode 6 için yollar değiştirildi (dcc yorumu için teşekkürler)! Ben sadece alternatif yolu ekledim.

Aşağıdaki kod satırıyla bir ram disk oluşturarak yapıları hızlandırmanın başka bir güzel yolu var:

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

Bu, yaklaşık 4 GB boyutunda bir bellek içi disk görüntüsü oluşturur. Ancak dikkatli olun, yeterli hafızaya sahip olmanız gerekir. Elbette 2 GB gibi daha küçük bir görüntü oluşturabilirsiniz (bu 4237927 olacaktır).

Sonra Xcode'a türetilmiş verileri orada depolamasını söylersiniz

Xcode'a iPhone Simulator verilerini doğrudan orada depolamasını söyleyemezsiniz, ancak bunu yaparak ramdisk üzerinde bir klasör oluşturabilir ve iPhone Simulator dizini yerine sembolik bir bağlantı oluşturabilirsiniz:

Xcode 6:

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

Daha eski Xcode sürümleri:

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

Bu kurulumla simülatör için geliştirirsem, anında çalışır ve çalışır :)

Makinenizi yeniden başlattığınızda ram diskinin kaybolacağını unutmayın, bu nedenle başlangıçta çalışan bir komut dosyası veya başka bir şey oluşturmak iyi bir fikir olabilir. VE SAKLAMAK İSTEDİĞİNİZ VERİLERİ YERLEŞTİRMEYİN !!!

GÜNCELLEME 2013-03-12:

1. Aşağıdaki Francisco Garcia'dan yorumu okuyun!

2. Yeni MBP'mle (SSD sürücüsü içeren) artık bu yönteme ihtiyacım yok. Xcode cehennem gibi çalışır :). Umarım bu, büyük meyve endişesi için bir reklam olarak görülmez, sadece bir deneyim raporu ...

Genel Tercihlerde Canlı Sorunları devre dışı bırakmak kesin bir fark yarattı. Ayrıca, sık sık yeniden çalıştırdığım durumlar için gdb etkin olmayan bir şema kuruyorum (gdb başlatmayı biraz hızlandırmıyor).

Benim için Xcode, 32 bit modunda çalışacak şekilde ayarlandıktan sonra (varsayılan olarak 64'tü) büyük bir performans artışı elde etti. Eski Xcode 3. olarak Sağdaki tıklayarak (Uygulamayı tarafından 32 bit geçebilirsiniz neredeyse hızlı /Developer/Applications/XCode.app ) ve seçme Bilgi Al ve denetleme 32 bit modunda Aç .

Xcode 4.2, 4.3:

Dosya dizinleyiciyle ilgili büyük sorunlar (yıllardır hatalı olan Spotlight'ı çalıştıran kodla aynı mı? Muhtemelen).

Dosyaları "izlemek" ile ilgili gerekli olmayan her şeyi devre dışı bırakın:

1. Hızlı Yardım (Not: QH sekmesine asla tıklamayın! Asistan'ı gizlemek bile kodun çalışmasına neden olur! Yeni bir dosyaya geçmeden önce farklı bir sekmeye geçin ...)
2. SCM yönetimi (SVN, Git, vb. - Xcode'un git desteği hala biraz hatalı (projeleri bozabilir) ve SVN desteğini bıraktılar, bu yüzden yine de kullanmamalısınız!)
3. çalışma alanı klasörünüzü silmeyi deneyin (kabul edilen cevaba göre), ancak yalnızca diskte büyükse
4. ... tek tek dosyaların durumuyla ilgili bulabileceğiniz diğer her şey

Xcode 4.4, 4.5:

Bu sürümlerde büyük bir mem sızıntısı, bozuk bir dosya dizinleyici (ancak 4.2 ve 4.3'ten daha iyi) ve belki de özel bir takas dosyası sorunu vardır.

Sonunda, takas alanını devre dışı bırakarak / etkinleştirerek ( mac os x'te takas nasıl devre dışı bırakılır veya etkinleştirilir ) ve birkaç makinede normal sabit diskler kullanarak ve 16 GB RAM'e kadar 2 GB RAM'e sahip makinelerde deneyler çalıştırarak, Xcode'u buldum. OS X takas alanından (!) bağımsız olarak kendi takas alanını çalıştırıyor gibi görünüyor.

(bu bir hata olabilir - belki de bilmediğim fazladan bir OS X takas şekli vardır - ancak sistem takas dosyaları daha büyük ya da küçülmezken, disk alanı bazı makinelerde gigabaytlarca yukarı ve aşağı atladı)

gözlemlenen:

1. Xcode 4.4 / 4.5, sisteminizdeki tüm RAM'i rasgele alır (küçük bir proje için 10 GB), böylece sistemin geri kalanı durma noktasına gelir, disk değiştirmeyi beklerken takılır

   1. KÖTÜ: SSD'li macbook'larda bunun olduğunu bilemezsiniz
   2. EN KÖTÜ: ... muhtemelen sabit diskinize zarar verse bile (SSD'ler yazma işlemlerinden hoşlanmaz)

2. Xcode, (bozuk) dahili dosya indekslemesini yapabilmesi için sabit diske erişimi kesecektir. Sistem belleği azaldığında ve OS X'in takas yapması gerektiğinde ... Xcode'un dosyaları indekslemesini beklerken takılır ... ve Xcode beklerken daha fazla bellek alır ... ve: BOOM! daha küçük sistemlerde, OS X sonunda kilitleniyor

3. Xcode, OS X takas alanına ihtiyaç duymaz

Sonuncusu çok ilginç. Çok fazla belleğiniz varsa (örn. 16 GB), takas alanını kalıcı olarak devre dışı bırakmayı deneyin. Xcode daha hızlı çalışır, çünkü OS X Lion, gerek duyulmadığında bile değiştiği mem yönetiminde bazı hatalara sahiptir .

Eğer xcode aniden yavaşlarsa, dahili olarak değişiyor, bu noktada onu öldürebilir ve yeniden başlatabilirsiniz.

(Eğer bir SSD'niz varsa, takasın başladığını bilmenin tek yolu, onun "yavaşlamasını" beklemektir. Aksi takdirde, HD thrash'i duyar duymaz bilirsiniz: artık sistem takas dosyası yoktur, yani tek olası neden Xcode'dur)

2GB RAM'iniz olsa bile takas işlemini güvenle devre dışı bırakabilirsiniz (bunu denediğimde ayda yalnızca bir OS X çökmesi yaşadım, bir yıl boyunca bu şekilde çalıştırdım), ancak bu, dosyalarla üst düzey video / grafik çalışmaları yapmanızı engelleyecektir. sadece çalıştırmak için çoklu gigabaytlara ihtiyaç duyar. Birkaç hafta denemekten çekinmeyin ve ne olacağını görün.

Ancak ... Xcode'u yavaşladığında yeniden başlatmak harikalar yaratır. Daha az RAM'e sahip makinelerde, Xcode'un özel takas dosyası kapattığınızda HEMEN siliniyor gibi görünüyor (çok fazla RAM içeren makinelerde görülmüyor)

Bu yanıtların hiçbiri benim durumumda performansı gerçekten iyileştirmedi (zamanla Xcode 4.1 neredeyse hiç kullanılamaz hale geldi, sadece şimdi çıkıp yardımcı oldu).

Ancak, tüm belgelerimi kapatmaya devam edersem (kontrol-komut-W) hızlı kalacağını yeni öğrendim. Xcode, tıkladığınız tüm belgeleri bir şekilde otomatik olarak bellekte tutar ve bunlar arasında kontrol-komut sol / sağ okları ile gezinebilirsiniz. Yanlışlıkla çok fazla açarsanız (özellikle IB pencereleri), durma noktasına gelir. Tüm açık dokümanları şimdi kapatmanız ve ardından tam bir yeniden başlatmaya gerek kalmadan bunu hafifletmiş gibi görünüyor.

@Lukasz tarafından yazılan aşağıdaki gönderi biraz yardımcı oldu, özellikle cevabındaki 8. madde (Kapalı Yardımcı Program Paneli ve Hızlı Yardım Bölmesi)

Xcode 4 aşırı derecede yavaşladı ve sabit diskimi öldürüyor

Bu sorunları yaşayan herkes, Mac OS X Lion'da Xcode 4.1'i denemelidir. Aynı donanımda (Macbook Pro 2.66 GHz Core 2 Duo 4GB RAM ile burada) ne kadar hızlı ve duyarlı olduğuna şaşırdım .

Sanırım bu sürümle tonlarca performans hatasını düzelttiler.

Aletleri zaman profili şablonuyla çalıştırın ve çalışan Xcode'a (veya sorununuz derleme sırasındaysa clang, llvm, vb.) Ekleyin. Sorunu oldukça hızlı görebilmelisiniz. Farklı makinelerde çok farklı nedenler gördüm. Sürüm kontrolü genellikle suçludur.

Ben de aynı sorunlarla karşılaşıyorum. Beta sürümleri hala kalıcı olduğu için kısmen düzeltildi. Görünüşe göre Xcode dahili olarak belleğinizde yüzen bir veya daha fazla sızıntıya sahip. Entegre Arayüz Oluşturucu'yu kullanırken bu şık "özelliği" çok iyi izleyebilirsiniz. Dua etmenin ve hata raporlarını Apple'a doldurmanın altında iki olası çözüm:

1. Dahili Builder'ı kullanmayın, bunun yerine harici uygulamayı başlatın.
2. Zaman zaman Xcode'dan çıkın, bu sızan belleği boşaltacaktır.

Bu başlıkta önerilen her şeyi ve [sayısız] diğerini denedim ve benim için işe yarayan tek şey, proje için yıkımı "devre dışı bırakmak" oldu. İşte boktan kısım - yerleşik SVN eklentisini "devre dışı bırakmanın" YALNIZCA / etc / hosts dosyamı sahte bir IP adresiyle dondurarak tüm SVN erişiminin başarısız olmasına neden olmaktı.

/ Developer / Library / Xcode / PrivatePlugIns içindeki IDESubversion.ideplugin'i kaldırmayı / yeniden adlandırmayı denedim, ancak Xcode 4.2.1 kusuyor ve başlamayı reddediyor.

Xcode'u her yeniden başlattığımda SVN depolarımı Xcode'dan kaldırmayı denedim, ancak Xcode birkaç dakika içinde çöküyor.

Dosya-> Kaynak Kontrolü-> Uzak Durumu Gizle aracılığıyla "Uzaktan Durum" u kapatmayı denedim (benim için hiçbir şey yapmadı).

Şimdi ana bilgisayar dosyamda SVN ana bilgisayar adımı 1.2.3.4 olarak ayarladığıma göre, Xcode harika çalışıyor ve dosyalar arasında neredeyse her geçiş yaptığımda SBBOD'u göstermiyor.

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

Sonra, gerçekten sürüm kontrolü yapmak istediğimde, hosts dosyasını açmam ve cmd line svn kullanmam gerekiyor.

Xcode'u endekslemekten kaçınabilirsiniz. Bunu yapmak, sisteminizin bellek performansını artıracak, ancak aynı zamanda otomatik tamamlama ve tanımlara atlama gibi IDE özelliklerinin çalışmasını da engelleyecektir.

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

Arayüz oluşturucu / düzenleyiciyle bir .xib dosyasını değiştirirken performansınız yavaşsa, .xib için Dosya Denetçisi altına gidin ve otomatik düzeni devre dışı bırakın . .Xib'de düzenlemelerinizi yapın, ardından son adım olarak otomatik düzeni yeniden etkinleştirin ve sınırlamalar ekleyin veya ayarlayın.

Sonunda git özelliğini kapatarak Xcode'umun normal çalışmasını sağladım.

Anlık görüntüleri burada açıklandığı gibi devre dışı bırakarak sorunumu çözdüm:

Film şeridini Xcode 5'te düzenlemek çok yavaş

Benim durumumda RAM kullanımıydı.

Birkaç Chrome sekmesini veya nadiren kullanılan uygulamaları kapatmayı deneyin.

XCode 4'ün derleme performansını hızlandırmak için bir numara buldum: Xcode'da çalıştırdığınızda veya derlediğinizde veya başka herhangi bir işlem yaptığınızda ve aktif monitörü açarken, Xcode işlemini seçin ve ardından örnek işleme tıklayın. İşlemin çözülmesini ve normal bir şekilde tekrar çalışmasını sağlayarak makul bir sürede uygulama oluşturmanıza olanak tanır.