1) si basa sul fatto che chiamare una funzione DLL utilizza sempre un salto indiretto aggiuntivo. Oggi, questo è generalmente trascurabile. All'interno della DLL c'è un po 'più di sovraccarico sulle CPU i386, perché non possono generare codice indipendente dalla posizione. Su amd64, i salti possono essere relativi al contatore del programma, quindi questo è un enorme miglioramento.
2) Questo è corretto. Con le ottimizzazioni guidate dalla profilazione, di solito puoi ottenere prestazioni del 10-15 percento circa. Ora che la velocità della CPU ha raggiunto i suoi limiti, varrebbe la pena farlo.
Vorrei aggiungere: (3) il linker può organizzare le funzioni in un raggruppamento più efficiente della cache, in modo da ridurre al minimo i costosi errori a livello di cache. Potrebbe anche influire in particolare sul tempo di avvio delle applicazioni (in base ai risultati che ho visto con il compilatore Sun C ++)
E non dimenticare che con le DLL non è possibile eseguire l'eliminazione del codice morto. A seconda della lingua, il codice DLL potrebbe non essere ottimale. Le funzioni virtuali sono sempre virtuali perché il compilatore non sa se un client lo sta sovrascrivendo.
Per questi motivi, nel caso in cui non vi sia alcuna reale necessità di DLL, utilizzare semplicemente la compilazione statica.
MODIFICA (per rispondere al commento, per sottolineatura dell'utente)
Ecco una buona risorsa sul problema del codice indipendente dalla posizione http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
Come spiegato x86 non li ha AFAIK per nient'altro che intervalli di salto a 15 bit e non per salti e chiamate incondizionati. Ecco perché le funzioni (dai generatori) con più di 32 KB sono sempre state un problema e avevano bisogno di trampolini incorporati.
Ma su sistemi operativi x86 popolari come Linux non è necessario preoccuparsi se il file .so / DLL non viene generato con lo gcc
switch -fpic
(che impone l'uso delle tabelle di salto indiretto). Perché se non lo fai, il codice viene semplicemente corretto come un normale linker lo riposizionerebbe. Ma mentre fa questo rende il segmento di codice non condivisibile e avrebbe bisogno di una mappatura completa del codice dal disco alla memoria e toccarlo tutto prima che possa essere utilizzato (svuotare la maggior parte delle cache, colpire i TLB) ecc. quando questo era considerato lento.
Quindi non avresti più alcun vantaggio.
Non ricordo quale sistema operativo (Solaris o FreeBSD) mi ha dato problemi con il mio sistema di compilazione Unix perché ho appena non stavo facendo questo e mi chiedevo perché si è arrestato fino a quando ho fatto domanda -fPIC
per gcc
.