Mi interesso principalmente sull'influenza che la raccolta di dati inutili avrebbe sulle prestazioni. L'uso della garbage collection è disapprovato per le app di rilascio?La garbage collection è utilizzata nelle app Cocoa di qualità di produzione?
Un'altra preoccupazione che posso pensare è che l'utilizzo della garbage collection potrebbe portare a una programmazione più scadente.
Utilizzi la garbage collection nelle tue app?
Garbage Collection è utilizzato in molte applicazioni di qualità di produzione. Xcode, Automator, Preferenze di sistema e molte altre applicazioni di sistema sono GC, e puoi aspettarti che questa tendenza continui nel tempo.
Inoltre, molti sviluppatori hanno adottato GC e lo stanno utilizzando esclusivamente nelle loro applicazioni. Ad esempio, le nuove versioni di Intuit di Quicken e QuickBooks per Mac sono spazzate via.
Ci sono anche molti vantaggi del GC. In cima alla mia testa e per esperienza personale:
rende più facile il multithreading; un'assegnazione semplice è una dichiarazione di proprietà atomica
scarica una serie di gestione della memoria su altri core; è naturalmente concorrente e alleggerisce un calcolo mazzo dal thread principale (o thread di calcolo)
in molti casi, l'allocazione e deallocazione può accadere interamente all'interno del contesto di un thread, eliminando così la necessità di sincronizzazione globale o bloccare
il raccoglitore è diventato più veloce con ogni versione di Mac OS X e tale tendenza continuerà (proprio come con il resto del sistema). Scaricando più carichi di calcolo della tua app sui framework forniti dal sistema, l'app guadagnerà sempre di più dalle ottimizzazioni al sistema sottostante.
poiché il collezionista ha una conoscenza approfondita del grafico dell'oggetto - dei puntatori tra gli oggetti - in memoria, rende l'analisi e il debugging molto più semplici. Invece di "da dove viene questo puntatore penzolante?", La domanda ora è "Dammi una lista di ragioni per cui questo oggetto si attacca più a lungo di quanto penso debba essere?".
Questo non vuol dire che non ci sia lavoro da fare per far funzionare correttamente l'applicazione in GC. Certamente ci sono tali compiti!
La raccolta dei rifiuti esiste dagli anni '60 e viene utilizzata in molte applicazioni rilasciate. Tutte le app .NET utilizzano la garbage collection. Apple utilizza libauto in Xcode.
La raccolta dei rifiuti in genere porta a un'app di qualità migliore in Cocoa poiché lo sviluppatore è libero dal carico di gestione della memoria. Ci sono tonnellate di app Cocoa che perdono! (anche se potrebbe non avere una quantità significativa di memoria)
Tendo ad usare gc dato che posso girare le mie app più velocemente e non devo preoccuparmi di messaggiare oggetti zombi!
Ci sono anche tonnellate di app raccolte dalla spazzatura che perdono. È molto probabile che perdano meno. – Lothar
Io uso GC ogni volta che posso, perché il codice migliore di tutti è il codice che non è necessario scrivere in primo luogo. Inoltre, come sottolineato in precedenza da Bbum, l'esecuzione in GC significa che sono disponibili molte più informazioni per l'analisi delle prestazioni, nel caso in cui sia necessario eseguire il debug di eventuali colli di bottiglia.
La raccolta dei rifiuti è consigliata per qualsiasi nuova applicazione Cocoa, e Apple mangia il proprio cibo per cani usandolo in Xcode. Le prestazioni sono una situazione interessante, perché mentre molto probabilmente consumerai più cicli della CPU in generale, l'applicazione potrebbe effettivamente finire più velocemente in alcune aree a causa del multithreading del collector e della semplificazione dei metodi accessor.
I computer sono fatti per funzionare per noi. Il conteggio dei riferimenti di Cocoa è solitamente facile da gestire, ma la raccolta dei rifiuti è un'altra cosa che può fare ora: lasciare che la macchina esegua il lavoro in modo da poter concentrarsi sulle cose che contano!
Come gli altri, consigliamo vivamente di utilizzare GC. Il sovraccarico delle prestazioni di solito è trascurabile! Non ho bisogno di ripetere i benefici come affermato da altri utenti.
Tuttavia, vorrei fortemente incoraggiare la scrittura di librerie, a differenza delle applicazioni, per l'esecuzione in modalità non GC. Alcuni ambienti non possono eseguire il codice GC, l'iPhone è il più notevole; quindi, se hai creato per te una libreria interna, che prevedi di riutilizzarla successivamente per un'app per iPhone, ti consiglio di progettarla in modo che possa funzionare anche in un ambiente non GC.
Convertire un codice GC in codice non GC è molto più difficile del contrario!
Nonostante alcuni ambienti (come iPhone e pre-Leopard) non supportino GC, è possibile compilare le librerie in modalità doppia. Ci vuole un po 'di lavoro in più, ma è certamente possibile. L'ho fatto io stesso per il framework CHDataStructures open-source. –
@Quinn, non posso essere più d'accordo. Tuttavia, ho chiarito il mio post per indicare che intendevo dire che le librerie dovrebbero essere scritte per essere utilizzabili in ambienti non GC. – notnoop
Buone informazioni. Grazie! – calvinlough
Vale la pena notare che la garbage collection è stata deprecata in 10.8. –
Vale la pena notare che il 10.11 sarà l'ultima versione di OS X per includere il runtime della garbage collection. Le app che utilizzano la garbage collection potrebbero non funzionare correttamente o non funzionare affatto il 10.12. – Andrew