Y at-il une différence entre la compilation de PHP avec le paramètre:Compiler php avec des modules vs utiliser des modules partagés?
--with-[extension name]
plutôt que de simplement compiler comme module partagé et y compris de cette façon? Y a-t-il un avantage de performance? Si non, pourquoi voudriez-vous faire cela?
Tout avantage lié aux performances serait négligeable. C'est simplement une autre option pour emballer votre build PHP.
Sur mon Mac j'utilise Marc Liyange’s build of PHP, qui inclut, entre autres, le support intégré de PostgreSQL. Il a été construit avec le drapeau --with-pdo-pgsql. Par conséquent, il n'a pas besoin d'être distribué avec la bibliothèque partagée pdo-pgsql.
S'il n'a pas construit avec --with-pdo-pgsql, il aurait dû distribuer la bibliothèque partagée pdo-pgsql et inclure une directive au php.ini pour le charger. Bien sûr, ce n'est qu'une petite différence, mais si vous savez que vous allez utiliser cette fonctionnalité, il est bon de la construire dans PHP lui-même.
Peut-être que ce ne sera pas une réponse complète à votre question, mais voici ce que j'ai pu trouver jusqu'à présent: il y a une réponse partielle dans le livre "Extension et incorporation PHP", écrit par Sara Golemon (amazon, certaines parties sont également disponibles sur google books).
La partie pertinente (une note en haut de la page 56) est:
jamais se demander pourquoi certaines extensions sont configurées à l'aide
--enable-extnameet certains sont configurés en utilisant--with-extename? Fonctionnellement, il n'y a pas de différence entre les deux. Dans la pratique , toutefois,--enablesignifie pour des caractéristiques qui peuvent être activées sans nécessiter de bibliothèques tierces .--with, en revanche, est destiné aux fonctionnalités qui ont ces conditions préalables .
Donc, pas un seul mot sur la performance (je suppose que, s'il y a une différence, il est seulement une question de « chargement d'un fichier plus » vs « chargement d'un fichier plus grand »); mais il y a une raison technique derrière cette possibilité.
Je suppose que cela est fait de sorte que PHP lui-même ne nécessite pas de une bibliothèque externe supplémentaire en raison d'une certaine extension; L'utilisation de la bonne option permet aux utilisateurs d'activer ou de désactiver eux-mêmes l'extension, selon qu'ils possèdent ou non déjà cette bibliothèque externe.
Je suppose que Nate a raison au sujet de la performance et que cette option ne sert qu'à l'emballage.
Fondamentalement, avec un module compilé, PHP peut appeler directement les fonctions du module, mais après la compilation, ces appels sont traduits en adresses mémoire à appeler.
Dans la version du module chargeable, PHP appellera un dl_open pour charger la librairie, puis appellera les fonctions par leurs adresses, comme le fait la version compilée.Je suppose que cet appel dl_open est fait une seule fois quand le serveur web est démarré, donc vous pouvez l'ignorer.
Peut-être une différence dans l'empreinte mémoire?
Corrigez-moi si je me trompe mais un module intégré sera dupliqué dans chaque processus chargé en mémoire (car il est lié statiquement) alors qu'un module partagé ne sera chargé qu'une seule fois et partagé par tous les processus php.
J'ai remarqué que lorsque toutes les fonctions sont chargées en tant que modules partagés, les pages php se chargent plus rapidement et l'utilisation du processeur est plus faible, mais certaines fonctions php en ligne de commande ne fonctionnent pas correctement. Il est logique de supposer qu'une configuration de module partagée est plus performante qu'un binaire statique de grande taille, car les modules ne seraient chargés que lorsque cela est nécessaire.