Xcode 4 - prestazioni lente

Ho un problema con Xcode 4 che risponde molto lentamente alle interazioni dell'utente, ad es. Modifica del codice, aree di scorrimento ecc. Ciò si verifica in particolare con progetti su larga scala con molti controller / file di visualizzazione, ecc.

Ho cancellato completamente il disco rigido e ho reinstallato Snow Leopard e Xcode l'altra settimana, ma si è verificato costantemente un tempo di risposta frustrante (per un certo numero di giorni), interrompendo notevolmente il flusso di lavoro.

In alcune occasioni ho anche rimosso i "dati derivati" del progetto tramite Organizer -> Progetti e questo ha avuto scarso effetto.

Mi chiedo se c'è qualcosa che posso fare per migliorare le prestazioni oltre a ottenere una macchina con specifiche più elevate in prima istanza.

Cordiali saluti, eseguo MacBook con processori Intel Core 2 Duo a 2 GHz e 4 GB di RAM.

Nel caso in cui avessimo bisogno di un aggiornamento, vorrei anche sapere se le persone stanno riscontrando queste scarse prestazioni da Xcode 4 su macchine ben congegnate (il che renderebbe il nostro aggiornamento hardware piuttosto inutile in quanto è solo Xcode che ha qualche problema di prestazioni sul MacBook).

Se qualcuno ha qualche suggerimento o suggerimento o potrebbe addirittura farci sapere in che modo l'hardware migliorerà le prestazioni di Xcode su alberi di progetto più grandi, ciò sarebbe estremamente utile e anche una risorsa preziosa per altri sviluppatori in una posizione simile.

Se si elimina il file dell'area di lavoro, è possibile accelerarlo.

Innanzitutto, assicurati che Xcode non sia aperto. Ora trova il tuo file di progetto. Fai clic destro su di esso e seleziona Show Package Contents.

Quindi, elimina project.xcworkspace.

Apri Xcode e goditi prestazioni più veloci!

Grazie a: http://meachware.blogspot.com/2011/06/speed-up-xcode-4.html

Modifica: ho ricevuto diversi commenti su questo fatto, sottolineando che per alcuni progetti ciò potrebbe causare problemi. Assicurati di avere un backup del tuo progetto prima di eseguire questi passaggi e non dimenticare di controllare e testare il tuo progetto in seguito . Assicurati di avere ancora tutti i tuoi eseguibili e schemi.

AGGIORNAMENTO IMPORTANTE: percorsi modificati per Xcode 6 (grazie per il commento dcc)! Ho appena aggiunto il modo alternativo.

C'è un altro bel trucco per fissare build creando un disco ram con la seguente riga di codice:

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

Questo crea un'immagine del disco in memoria con una dimensione di circa 4 GB. Ma fai attenzione, devi avere abbastanza memoria. Ovviamente puoi creare un'immagine più piccola come 2 GB (sarebbe 4237927).

Quindi dici a Xcode di memorizzare lì i dati derivati

Non puoi dire a Xcode di archiviare i dati di iPhone Simulator direttamente lì, ma puoi creare una cartella sul ramdisk e creare un collegamento simbolico invece della directory di iPhone Simulator in questo modo:

Xcode 6:

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

Versioni precedenti di 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

Se costruisco per il simulatore con questa configurazione, è attivo e funzionante in pochissimo tempo :)

Tenere presente che il disco ram scompare quando si riavvia il computer, quindi potrebbe essere una buona idea creare uno script o qualcosa che viene eseguito all'avvio. E NON DETERMINARE ALCUN DATI CHE VUOI MANTENERE !!!

AGGIORNAMENTO 2013-03-12:

1. Leggi il commento di Francisco Garcia qui sotto!

2. Con il mio nuovo MBP (contenente un'unità SSD) non ho più bisogno di questo metodo. Xcode funziona come l'inferno :). Spero che questo non sia visto come pubblicità per la grande preoccupazione della frutta, è solo un rapporto sull'esperienza ...

La disabilitazione di Problemi in tempo reale nelle Preferenze generali ha fatto la differenza. Ho anche impostato uno schema senza gdb abilitato per le situazioni in cui sto spesso rieseguendo (nessun gdb accelera il lancio abbastanza).

Per me, Xcode ha ottenuto un enorme aumento delle prestazioni dopo averlo impostato per l'esecuzione in modalità 32 bit (era 64 per impostazione predefinita). È quasi veloce come il vecchio Xcode 3. Puoi passare a 32 bit facendo clic con il pulsante destro del mouse sull'app (in /Developer/Applications/XCode.app ) e selezionando Ottieni informazioni e selezionando Apri in modalità a 32 bit .

Xcode 4.2, 4.3:

Principali problemi con l'indicizzatore di file (lo stesso codice che esegue Spotlight, che è stato danneggiato per anni? Probabilmente).

Disabilita tutto ciò che non è essenziale per "guardare" i file:

1. Guida rapida (NB: non fare mai clic sulla scheda QH! Anche nascondere l'Assistente provoca comunque l'esecuzione del codice! Passare a una scheda diversa prima di passare a un nuovo file ...)
2. Gestione SCM (SVN, Git, ecc. - Il supporto git di Xcode è ancora un po 'difettoso (può corrompere i progetti) e hanno abbandonato il supporto SVN, quindi non dovresti usarlo comunque!)
3. prova a eliminare la cartella dell'area di lavoro (come da risposta accettata), ma solo se è grande sul disco
4. ... qualsiasi altra cosa che puoi trovare in relazione allo stato dei singoli file

Xcode 4.4, 4.5:

Queste versioni presentano una perdita di mem maggiore, un indicizzatore di file non funzionante (ma migliore di 4.2 e 4.3) e forse un problema di file di scambio privato.

Alla fine, disabilitando / abilitando lo spazio di swap ( come disabilitare o abilitare lo scambio in mac os x ) e usando i normali dischi rigidi su più macchine, ed eseguendo esperimenti su macchine con 2 GB di RAM fino a 16 GB di RAM, ho scoperto che Xcode sembra eseguire il proprio spazio di swap, indipendentemente dallo scambio di OS X (!).

(questo potrebbe essere un errore - forse c'è una forma extra di scambio di OS X che non conosco - ma i file di scambio di sistema non sono diventati più grandi o più piccoli, mentre lo spazio su disco è saltato di gigabyte su e giù su alcune macchine)

osservato:

1. Xcode 4.4 / 4.5 prenderà casualmente tutta la RAM del tuo sistema (10 GB di GB per un piccolo progetto) in modo che il resto del sistema si fermi, bloccato in attesa dello scambio del disco

   1. PEGGIORE: sui macbook con SSD, non saprai che è successo
   2. PEGGIORE: ... anche se probabilmente sta danneggiando il tuo disco rigido (agli SSD non piacciono le scritture thrashing)

2. Xcode consentirà l'accesso al disco rigido in modo che possa eseguire l'indicizzazione dei file interni (non funzionanti). Quando la memoria di sistema si esaurisce e OS X deve effettuare lo scambio ... si blocca in attesa che Xcode indicizzi i file ... e Xcode occupi più memoria mentre attende ... e: BOOM! su sistemi più piccoli, OS X alla fine si blocca

3. Xcode non ha bisogno di spazio di scambio OS X.

L'ultimo è molto interessante. Se hai molta memoria (ad es. 16 GB), prova a disabilitare lo spazio di scambio in modo permanente. Xcode funziona più velocemente, perché OS X Lion ha alcuni bug nella gestione dei mem dove si scambia anche quando non è necessario .

Se xcode rallenta improvvisamente, si sta scambiando internamente, a quel punto puoi semplicemente ucciderlo e riavviarlo.

(se hai un SSD, l'unico modo per sapere se ha iniziato a scambiare è aspettare che "rallenti". Altrimenti, sai non appena senti il ​​thrash HD: non c'è più alcun file di scambio di sistema, quindi il l'unica causa possibile è Xcode)

Puoi disabilitare in modo sicuro lo swap anche se hai 2 GB di RAM (ho avuto solo un arresto anomalo di OS X al mese quando l'ho provato, lo ho eseguito in questo modo per un anno), ma ti impedirà di lavorare con video / grafica di fascia alta con i file che hanno bisogno di multi-gigabyte solo per funzionare. Sentiti libero di provarlo per alcune settimane e vedere cosa succede.

Ma ... riavviare Xcode ogni volta che rallenta funziona a meraviglia. Su macchine con meno RAM, il file di scambio privato di Xcode sembra cancellarsi IMMEDIATAMENTE quando si chiude (non sembra accadere su macchine con molta RAM)

Nessuna di queste risposte ha davvero migliorato le prestazioni nel mio caso (nel tempo Xcode 4.1 è diventato difficilmente utilizzabile, abbandonandolo solo ora e poi aiutato).

Tuttavia, ho appena scoperto che se continuo a chiudere tutti i miei documenti (control-command-W) sembra che rimanga veloce. Xcode conserva automaticamente tutti i documenti su cui fai clic in memoria e puoi navigare tra di loro con la freccia sinistra / destra di controllo-comando. Se ne apri accidentalmente troppi (in particolare le finestre IB), si blocca. Basta chiudere tutti i documenti aperti ora e poi sembra alleviare questo senza la necessità di fare un riavvio completo.

Il seguente post di @lukasz ha aiutato un po ', in particolare il suo articolo n. 8 nella sua risposta (Pannello delle utilità chiuso e riquadro della Guida rapida)

Xcode 4 è diventato estremamente lento e ha ucciso il mio disco rigido

Tutti coloro che riscontrano questi problemi dovrebbero provare Xcode 4.1 su Mac OS X Lion. Sono sorpreso di quanto sia più veloce e reattivo sullo stesso hardware (Macbook Pro 2,66 GHz Core 2 Duo con 4 GB di RAM qui).

Suppongo che abbiano risolto un sacco di errori prestazionali con questa versione.

Accendi gli strumenti con il modello di profilo temporale e collegalo all'Xcode in esecuzione (o clang, llvm, ecc. Se il tuo problema è durante le build). Dovresti essere in grado di vedere il problema abbastanza rapidamente. Ho visto cause molto diverse su macchine diverse. Il controllo della versione è spesso un colpevole.

Sto affrontando gli stessi problemi. Sono stati parzialmente risolti poiché i build beta sono ancora persistenti. Sembra che Xcode internamente abbia una o più perdite che fanno galleggiare la tua memoria. Puoi guardare questa bella "caratteristica" molto bene quando usi l'Integrated Interface Builder. Due possibili soluzioni sotto pregare e riempire segnalazioni di bug a apple:

1. Non usare Builder interno, avvia invece l'applicazione esterna.
2. Chiudere Xcode di volta in volta, questo dovrebbe liberare la memoria che era trapelata.

Ho provato praticamente tutto ciò che è stato suggerito in questo thread e [numerosi] altri e l'unica cosa che ha funzionato per me era "disabilitare" la sovversione per il progetto. Ecco la parte scadente - L'UNICO modo in cui potevo "disabilitare" il plug-in SVN incorporato era quello di fregare il mio file / etc / hosts con un indirizzo IP falso, causando in modo errato tutto l'accesso SVN.

Ho provato a rimuovere / rinominare IDESubversion.ideplugin in / Developer / Library / Xcode / PrivatePlugIns, ma Xcode 4.2.1 vomita e si rifiuta di avviarsi.

Ho provato a rimuovere i miei repository SVN da Xcode ogni volta che riavvio Xcode, ma Xcode si arresta in modo anomalo in pochi minuti.

Ho provato a disattivare "Stato remoto" tramite File-> Controllo sorgente-> Nascondi stato remoto (non ha fatto nulla per me).

Ora che ho impostato il mio nome host SVN su 1.2.3.4 nel mio file hosts, Xcode funziona alla grande e non mostra SBBOD quasi ogni volta che passo da un file all'altro.

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

Quindi, quando voglio davvero fare il controllo della versione, devo decomprimere il file hosts e usare cmd line svn.

Puoi evitare di indicizzare Xcode. In questo modo migliorerai le prestazioni della memoria del tuo sistema, ma impedirai anche il funzionamento delle funzionalità IDE come il completamento automatico e il passaggio alle definizioni.

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

Se hai prestazioni lente durante la modifica di un file .xib con il builder / editor dell'interfaccia, vai in Controllo file per .xib e disabilita il layout automatico . Apporta le modifiche a .xib, quindi come passaggio finale, riattiva il layout automatico e aggiungi o modifica i vincoli.

Finalmente sono riuscito a far funzionare normalmente il mio Xcode disattivando la funzione git.

Ho risolto il mio problema disabilitando le istantanee come descritto qui:

La modifica dello storyboard in Xcode 5 è molto lenta

Nel mio caso, è stato l'utilizzo della RAM.

Prova a eliminare alcune schede di Chrome o app utilizzate raramente.

Ho trovato un trucco per accelerare le prestazioni di compilazione di XCode 4: quando esegui o compili o esegui qualsiasi altra elaborazione in Xcode e si blocca il monitor attivo aperto, seleziona il processo Xcode quindi fai clic sul processo di esempio. Renderà il processo sbloccato e riavviato normalmente, consentendo di creare un'app in un tempo ragionevole.