malcom-mac.com

Prebinding, il mito

Posted on the December 14th, 2006 under Mac, Programmazione, Tutorial by Daniele Margutti

Facciamo un altro salto dentro Mac OS X per scoprire se davvero tutti quei programmi che promettono di rivitalizzare il nostro OS (se ce ne fosse bisogno, cosa davvero poco probabile) fanno davvero qualcosa al computer o solo all’utente. Effetto placebo docet (e qui inizio a prendere le parti).
Parliamo quindi del prebinding.

Sotto Mac OS X esiste un meccanismo chiamato prebinding che viene utilizzao per accellerare l’avvio delle applicazioni. Come in ogni sistema operativo moderno, vuoi per minimizzare lo spreco di risorse, vuoi per motivi di stabilità (pensate se ogni programma che vuole avere un controllo browser web debba riscriverlo da zero) le applicazioni sono composte da più parti e non da un singolo eseguibile (questi componenti aggiuntivi nella maggior parte dei casi sono librerie linkate dinamicamente o framework). Alcune di queste librerie sono disponibili a livello di sistema operativo (lo stesso WebKit, ma anche i vari framework per comunicare con l’OS. Apple in questo senso ne mette a disposizione oltre 150), altre sono scritte da programmatori esterni.

Anzichè includere queste librerie all’interno del package del programma direttamente (ogni applicazione è in realtà una cartella nascosta, visibile tramite il comando “show contents of package” con un ctrl-click sull’icona) utilizzando quello che è chiamato Static Linking, i programmatori possono linkare dinamicamente le librerie al programma (Dynamic Linking appunto).

I vantaggi derivanti dall’uso del linking dinamico sono diversi: prima di tutto se più applicazioni utilizzano lo stesso framework (un framework non è altro che un contenitore per librerie) Mac OS X permetterà di condividere la porzione di memoria in cui il framework è contenuto, evitando quindi uno spreco inutile di memoria.
Inoltre le applicazioni che utilizzano quel framework non dovranno perdere del tempo per caricarlo di nuovo e l’avvio sarà quindi velocizzato.

L’uso dei framework permette inoltre una maggiore stabilità come vantaggio indiretto. Il fatto che Apple rilasci periodicamente aggiornamenti dei componenti fa si che tutte le applicazioni che ne fanno uso siano automaticamente aggiornate contro eventuali problemi e aggiunte di funzionalità.

Torniamo ora al funzionamento del prebinding prima di sparlare un pò sul tema principale del post.
Quando un programma linka una libreria (contenente una gran quantità di funzioni utili e non al programma) deve cercare tutte le funzioni prima di usarle. Ogni funzione, classe, costante o variabile locale o globale è rappresentata da un simbolo.

Una volta che l’applicazine esegue il binding (quindi un “collegamento”) con le librerie questa potrà utilizzare le funzioni della libreria stessa.
Il processo di binding ovviamente consuma del tempo. Al tempo stesso ogni libreria può linkarne altre così che il numero dei binding da eseguire può facilmente aumentare drasticamente.

Eliminare questo binding manuale quindi può velocizzare il lancio delle applicazioni.
Quando una applicazione o una libreria è prebound significa che la libreria contiene una cache di tutti i simboli necessari per il binding e quindi è pronta per l’uso. Al lancio dell’applicazione questa utilizzerà quindi automaticamente la cache di tutti i simboli necessari senza dover perdere tempo a crearla da zero.

Ogni qual volta viene resa disponibile una nuova versione della libreria, tutti i simboli su cui è stata creata la cache non sono più validi. Quando questo succede è necessario quindi ricrearli; ci pensa OS X automaticamente a verificare e quindi operare se necessario.

Ci sono degli aspetti di Mac OS X che sono, per così dire incompresi, o abusati dagli utenti. Il prebinding è uno di questi. Il mito che accompagna questa “tradizione” nasce quando, qualche anno fà venne distribuita una piccola applicazione chiamata Xoptimize. Xoptimize nasce come risposta ad una domanda sul prebinding ai tempi delle prime release di OS X.
Dal 10.2 tuttavia il prebinding è automatico e a carico del sistema, eseguito dalla componente dyld (man sul terminale per saperne di più) - (Soltanto con il 10.1 e precedenti il prebinding quindi poteva essere utile). In particolare quando dyld individua che le informazione di un’applizione sul prebinding non sono più valide per il sistema, manda un messaggio a match_init (il demone di mach per il dispatiching delle comunicazioni) che a sua volta esegue il fix (fix_prebinding) delle informazioni.
Per i più curiosi l’operazione di prebinding può essere visalizzata con tail -f /var/log/system.log dalla finestra di terminale).

Da lato programmatore, per visualizzare le informazioni di cache dell’applicazione sul prebinding basta aggiungere la variabile d’ambiente DYLD_PREBIND_DEBUG.

Quindi l’operazione di prebinding che trovate su XOptimize, OnyX e compagnia bella è del tutto inutile (in verità è più probabile che sprechiate più tempo nell’aspettare il prebinding completo manuale piuttosto che nel farlo fare a OS X se mai si rendesse necessario).
I comandi per il prebinding sono principalmente 3: fix-predibing(8), redo_predibing(1) e update_prebinding(1) (il numero accanto serve per trovare la relativa pagina del manuale dal terminal).

Materiale Bibliografico utilizzato:
- Prebinding & linked articles (Wikipedia)
- Prebinding on Mac OS X 10.2 (Apple Technical Docs)
- Mantaining Mac OS X (XLabs)
- Prebinding Explained (BBum’s Rat)
- Chat with guys at #macdev (freenode network)
[tags]prebinding mac os x, prebinding, onyx, ottimizzare macos x, onyx prebinding[/tags]