Il existe deux types de langages de programmation : interprétés et compilés. Quel langage est PHP ? Afin de répondre à cette question, nous devons comprendre la terminologie.

Un programme qui traduit du code écrit dans un langage de programmation dans un autre est appelé traducteur. Un compilateur est aussi un traducteur. Il traduit le code écrit dans un langage de haut niveau en code machine. Le processus de compilation crée un fichier exécutable binaire qui peut être exécuté sans compilateur.

Un interprète est une catégorie complètement différente. L'interpréteur ne traduit pas le code, mais l'exécute. L'interpréteur analyse le code du programme et en exécute chaque ligne. Chaque fois que vous exécutez un tel code, vous devez utiliser un interpréteur.

En termes de performances, les interpréteurs sont nettement inférieurs aux compilateurs, car le code binaire s'exécute beaucoup plus rapidement. Mais les interprètes permettent de contrôler totalement le programme lors de son exécution.

Quant à PHP, ce n'est ni un compilateur ni un interpréteur. PHP est un croisement entre un compilateur et un interpréteur. Essayons de comprendre cela et regardons comment PHP traite le code.

Regardons l'image :

On voit que PHP est composé de deux blocs quasiment indépendants : un traducteur et un interpréteur. Pourquoi aviez-vous besoin de faire ça ? Bien sûr, pour des raisons de rapidité.

L'entrée PHP est un script. Il le traduit (le traduit), en vérifiant la syntaxe, en un bytecode spécial (représentation interne). PHP exécute ensuite le bytecode (pas le code du programme lui-même), mais ne crée pas de fichier exécutable.

Le bytecode est beaucoup plus compact que le code de programme ordinaire, il est donc plus facile (et plus rapide) à interpréter (exécuter). Jugez par vous-même : l'analyse n'est effectuée qu'une seule fois au stade de la traduction et un « produit semi-fini » est exécuté - le bytecode, ce qui est beaucoup plus pratique à ces fins. Par conséquent, PHP est plus un interpréteur qu’un compilateur. Ce « double travail » était nécessaire aux fins suivantes.

Considérez la boucle :

Pour (i=0;i<10; i++) { Operator_1; Operator_2; Operator_3; ............ Operator_99; Operator_100; }

Ce cycle « tournera » 10 fois. Pour chacune de ces dix passes, l'interprète doit 100 lignes de code. Et il doit analyser et exécuter 10*100 = 1000 lignes de code ! Si vous convertissez une fois la boucle entière en bytecode, alors elle devra analyser 10 fois moins ! Cela signifie que les scripts s’exécuteront 10 fois plus vite !

Il s'avère que PHP l'est.

La phase principale du travail de PHP est l'interprétation de la représentation interne du programme et son exécution. C’est cette phase qui prend le plus de temps dans les scénarios sérieux. Toutefois, le ralentissement n’est pas si important.

Il convient de rappeler que PHP version 3 était un interpréteur « pur » et qu'avec PHP 4, les scripts ont commencé à s'exécuter beaucoup plus rapidement, puisque PHP version 4 (et PHP5) est un traducteur interprétatif.

Le langage Perl, qui est presque toujours appelé compilateur, fonctionne exactement de la même manière : il traduit le texte du programme en une représentation interne, puis utilise le code résultant lors de l'exécution. Nous pouvons donc dire que PHP version 4 est un compilateur exactement de la même manière que Perl.

Nous sommes donc obligés de conclure que PHP est un interpréteur avec un bloc de traduction intégré qui optimise le flux d'interprétation.

Utiliser un interpréteur (et donc PHP) présente des avantages indéniables :

• Il n'y a pas lieu de s'inquiéter de la libération de la mémoire allouée, il n'est pas nécessaire de fermer les fichiers lorsque vous avez fini de travailler avec eux - l'interprète fera tout le travail de routine, puisque le programme est exécuté sous son contrôle vigilant ;
• Il n'est pas nécessaire de penser aux types de variables, ni de déclarer une variable avant sa première utilisation ;
• Le débogage des programmes et la détection des erreurs sont grandement simplifiés - l'interprète a un contrôle total sur ce processus ;
• Dans le contexte des applications Web, l'interpréteur présente également un avantage très important : il n'y a aucun risque de « geler » le serveur si le programme ne fonctionne pas correctement.

Il existe également d’autres avantages. De manière générale, l’utilisation d’un interpréteur peut donner aux scripts la puissance que les utilisateurs Web attendent d’eux.

La baisse de performances de PHP est perceptible dans le cas de boucles volumineuses et complexes, lors du traitement d'un grand nombre de lignes, etc. Notez cependant que c'est le seul inconvénient de PHP, qui apparaîtra de moins en moins à mesure que sortiront des processeurs plus puissants. , pour finalement disparaître complètement.

<<< Назад (Quoi de neuf dans PHP5 ?)

Contenu

Suivant >>> (Transition vers PHP 5.3)

Si vous avez d'autres questions ou si quelque chose n'est pas clair, bienvenue sur notre

La compilation de PHP à partir du code source se fait souvent sur des systèmes de type Unix. Ceux qui travaillent dans un environnement Windows téléchargeront et installeront très probablement PHP à partir de packages binaires. Et même si je ne suis pas d'accord sur le fait qu'il s'agit d'une solution précompilée plus facile à utiliser, même sur les systèmes Unix, la compilation d'un binaire à partir des sources présente certains avantages. En tout:

• Vous avez la possibilité d’affiner le produit final lors de la compilation. Peut-être souhaitez-vous une certaine extension qui se compile directement dans le binaire plutôt que de le charger en tant que bibliothèque externe. Ou peut-être souhaitez-vous désactiver quelque chose qui est généralement disponible par défaut.
• Vous pouvez faire une astuce, pendant le processus de compilation si nécessaire, qui peut améliorer les performances d'un environnement spécifique (bien sûr, cela suppose que vous savez déjà ce que vous faites dans ce cas tu ne lirais pas cet article !).
• La compilation peut être le seul moyen de faire fonctionner les choses si les binaires compilés ont été construits sur d'anciennes versions de logiciels et de bibliothèques de support et que vous utilisez maintenant un nouveau système.

Avertissement: la compilation peut être frustrante, surtout sous Windows ! Vous devez vous assurer que l'environnement de construction est correctement configuré, apprendre à utiliser correctement le compilateur et les autres outils de construction et satisfaire toutes les dépendances de la bibliothèque. Nous espérons que cet article sera votre première étape pour surmonter bon nombre de ces obstacles.

Configuration de l'environnement de construction

PHP est écrit en C et un compilateur C est donc requis si vous souhaitez créer PHP à partir du code source. C++ est une super suite de C, donc un bon compilateur C++ devrait être capable de compiler du code C, et bien que ce ne soit pas toujours le cas. Pour Windows, Visual Microsoft, C++ Express (qui s'appellera plus tard VC++) est disponible gratuitement sur le site de Microsoft. L'édition 2010 a été utilisée.

Lorsque vous choisissez une version du compilateur, vous devez garder à l’esprit la manière dont vous exécuterez PHP. Si vous devez travailler avec mod_php des binaires Apache officiellement compilés et que vous souhaitez compiler PHP à l'aide de Visual Studio 6, puisqu'il s'agit de la version de compilation Apache. Le module doit cibler la même bibliothèque d'exécution qu'Apache, en l'occurrence msvcrt.dll. Si vous construisez également Apache à partir des sources, ou si vous envisagez d'exécuter PHP en tant que FastCGI ou CLI, ce n'est pas un problème et 2010 fonctionnera correctement.

Vous devez également installer le logiciel Windows Development Kit (SDK). Le SDK nous donne les fichiers d'en-tête importants pour la plate-forme Windows dont nous aurons besoin pour compiler avec succès. Là aussi, la version 7.1 a été utilisée.

Installez le compilateur puis le SDK. Je ne discuterai pas de l'installation car les deux disposent d'un assistant d'installation graphique qui vous guidera tout au long du processus.

Si vous disposez d'une version de compilateur fonctionnelle, téléchargez les outils binaires et les packages connus depuis windows.php.net. Le package d'outils binaires (j'utilise l'archive 20110915) contient des outils de développement tels que re2c, bison et quelques commandes supplémentaires dont vous aurez besoin pour créer PHP. Le package connu (j'utilise l'archive 5.4 car elle correspond à la version de PHP que je vais compiler) contient les en-têtes minimaux et les bibliothèques de dépendances nécessaires, par exemple zlib.h.

Il va probablement sans dire que vous souhaitez également télécharger les sources PHP depuis windows.php.net. Au moment d'écrire ces lignes, la version actuelle de PHP est la 5.4.6, c'est donc le numéro de version que vous verrez dans les exemples.

C'est une bonne idée de créer un espace de travail dans lequel vous pouvez extraire le code source et le compiler afin qu'il n'affecte pas le reste de votre système. Créez un dossier C:\PHP-Dev qui vous servira de répertoire de travail, puis extrayez-y l'archive binaire et les outils.

Ensuite, extrayez le contenu de l'archive, la source PHP dans C:\PHP-Dev maintenant vous avez php5.4 dans le dossier source, puis extrayez son archive deps dans le dossier frère deps. La structure des répertoires devrait ressembler à ceci :

Ouvrez l'invite de commande du SDK Windows qui a été installée avec le SDK (Démarrer => SDK Microsoft Windows => Invite de commande du SDK Windows) et exécutez les commandes suivantes :

Setenv /release /xp /x86 cd C:\PHP-Dev bin\phpsdk_setvars.bat

L'utilisation de la ligne de commande de la console SDK est préférable à la console cmd.exe standard, car elle définit de nombreuses variables d'environnement spécifiques à la compilation du code source. Les compilations de commandes ultérieures doivent également être effectuées dans cette console.

setenv définit certaines propriétés de build pour l'environnement, dans ce cas, l'environnement cible est la version Windows XP 32 bits de la build. Vous pouvez essayer de construire avec /x64 si vous recherchez l'aventure. La définition de différentes versions de Windows telles que /Vista entraînera très probablement des problèmes de sortie en raison de définitions étranges dans les scripts (PHP veut toujours être compatible avec XP). À moins que vous ne sachiez vraiment ce que vous faites, il est probablement plus sûr de s'en tenir aux valeurs recommandées que j'ai utilisées ci-dessus.

Le script phpsdk_setvars.bat accède à certaines variables d'environnement supplémentaires, le processus de construction a pu trouver les outils binaires.

Gardez à l'esprit que tous ces paramètres variables ne sont que des sessions temporaires dans la console. Si vous fermez tout rapidement pour revenir compiler plus tard, vous devrez réexécuter la commande, et si vous ne le faites pas, vous obtiendrez des erreurs comme celles-ci, lorsque vous exécuterez configure plus tard, vous ne pourrez pas continuer :

Recherche de bison.exe... ERREUR : le bison est requis

S'assurer que vous disposez du bon environnement de construction, des sources requises et des éventuelles dépendances est la partie la plus difficile du processus. Alors maintenant que votre environnement est configuré avec le code source et les dépendances en place, il est temps de compiler !

Compilation de PHP

Sur la ligne de commande du SDK, accédez au dossier source PHP et exécutez buildconf. La commande est chargée de générer les fichiers de configuration qui seront créés par le Makefile pour contrôler le processus de compilation.

Une fois buildconf terminé (cela ne prendra qu'une seconde), exécutez configure --help - et examinez l'aide pour connaître les fonctionnalités que vous souhaitez activer/désactiver, puis exécutez à nouveau configure avec l'option de votre choix. C'est une bonne idée de vérifier le résultat avant de déplacer, car cela vous avertira si l'une des dépendances requises n'est pas disponible. Si cela se produit, vous pouvez soit installer les dépendances et réexécuter la configuration, soit ajuster les appels pour désactiver les extensions qui en ont besoin.

Enfin, exécutez NMAKE pour lancer la compilation.

Cd C:\PHP-Dev\php5.4 buildconf configurer nmake nmake test

Si une configuration ou NMAKE échoue, le problème est l'un des deux : premièrement, l'environnement n'est pas configuré correctement, deuxièmement, vous avez activé une fonctionnalité qui dépend de bibliothèques externes et les bibliothèques ne sont pas installées sur votre système. Vérifiez à nouveau que vous avez créé l'environnement conformément aux instructions ci-dessus et que toutes les bibliothèques supplémentaires pouvant être requises dans les paramètres de configuration sous-jacents ont été configurées.

Lorsque le premier NMAKE du processus de compilation est terminé, vous trouverez vos tout nouveaux fichiers PHP dans le dossier Release_TS. Le test NMAKE exécute de nouveaux tests d'erreur à double capacité pour garantir que tout fonctionne comme il se doit. Les résultats des tests NMAKE sont envoyés à l'équipe QA qui en dépend pour améliorer PHP, donc cela peut prendre quelques minutes pour y travailler, c'est un gros problème.

À ce stade, vous pouvez également profiter de l'étape supplémentaire consistant à exécuter le composant logiciel enfichable NMAKE, qui créera des archives ZIP et des fichiers binaires que vous pourrez copier.

Extensions de compilation

Il existe deux manières de compiler des extensions PHP : statiquement et dynamiquement. Une extension compilée statiquement est compilée dans un binaire PHP, tandis qu'une extension compilée dynamiquement est une DLL distincte qui peut être chargée ultérieurement via un fichier php.ini. Les extensions sont généralement compilées sous forme de DLL, bien que la compilation statique présente certains avantages et, en fin de compte, cela dépend de vos besoins.

Pour compiler des extensions PHP sous Windows, extrayez le dossier d'extension de code source dans le dossier ext de votre répertoire source PHP. Ensuite, reconfigurez le script en exécutant buildconf --force et en recompilant PHP en utilisant les options appropriées pour activer l'extension.

A titre d'exemple, compilons l'extension AOP de manière statique. Téléchargez le code source depuis PECL et extrayez-le dans un dossier, ext. Suivez ensuite ces étapes :

Cd C:\PHP-Dev\php5.4 buildconf --force configure --enable-aop nmake

L'option --force, buildconf l'oblige à restaurer le script de configuration. Ensuite, exécutez configure --help et vous devriez voir l'option permettant d'activer la nouvelle extension dans la sortie. Dans ce cas, il s'agit de --enable-AOP.

Lorsque nmake aura terminé, vous aurez un binaire PHP nouvellement construit avec AOP.

Les extensions seront disponibles sous forme de DLL plutôt que cuites en PHP, vous pouvez suivre les mêmes étapes que ci-dessus mais en spécifiant "partagé" comme valeur de configuration autorise l'option.

Buildconf --force configure --enable-aop=shared

Par conséquent, la DLL sera dans le dossier Release_TS avec le binaire PHP à la fin de la compilation, dans ce cas, le nom est php_aop.dll .

P.S.

Compiler sous Windows reste encore un peu délicat, surtout lorsqu'il s'agit d'extensions. Être capable de compiler du code source est une bonne compétence, surtout si vous souhaitez changer PHP ultérieurement.

L'article a été préparé pour vous par l'équipe du site
Article original :
Traduit par : Victor Klim

Alexeï Romanenko : Je m'appelle Alexey Romanenko, je travaille chez RBC. Le sujet de ce rapport est quelque peu controversé. Il semblerait, pourquoi compiler des scripts PHP alors que tout semble fonctionner comme ça ?

La question principale est probablement : « Pourquoi ? » De manière générale, le but de cette présentation est d'essayer de comprendre si une telle compilation est nécessaire, si oui, pourquoi, sous quelle forme et à qui.

Qu'est-ce qu'un compilateur PHP ?

Tout d’abord, un bref aperçu de ce qu’est un compilateur PHP. Je vais vous expliquer comment cela fonctionne, ce que c'est et comment vous pouvez l'accélérer.

Le premier module fonctionnel est ce qu'on appelle SAPI (Server API), qui fournit une interface pour accéder à PHP à partir de divers clients (Apache, une sorte de serveur CGI (Common Gateway Interface) et autres). Il existe également SAPI intégré, qui vous permet d'intégrer PHP dans n'importe quelle application.

La deuxième partie principale est PHP Core, qui traite les requêtes, implémente tous les travaux avec le réseau, le système de fichiers et analyse les scripts eux-mêmes.

La troisième partie globale est le Zend Engine, qui compile nos scripts en bytecode, l'exécute sur sa machine virtuelle et gère la gestion de la mémoire (implémente des allocateurs complets).

L'une des parties les plus importantes et les plus volumineuses est le module d'extensions, qui implémente 99 % de ce que nous utilisons en PHP. Il s'agit soit de « wrappers » pour certaines bibliothèques, soit de fonctionnalités, soit de classes, de bibliothèques intégrées, etc. Nous pouvons également écrire nos propres extensions.

Comment le script lui-même est-il exécuté ?

D'abord. Une analyse lexicale a lieu - le fichier est téléchargé, analysé, tous les caractères de l'ensemble de ce fichier sont traduits en un certain ensemble de jetons, avec lesquels nous travaillons ensuite.

La phase d'analyse analyse ces jetons. Sur la base de cette analyse, une certaine structure grammaticale est élaborée, sur la base de laquelle le bytecode sera ensuite généré.

À la fin, Zend Engine l'exécute. Le résultat est renvoyé au client.

Nous parlons de charges élevées. Si vous répétez ce schéma d’actions à chaque fois, tout fonctionnera très lentement. Lorsque notre interprète reçoit plusieurs centaines ou milliers de demandes en même temps, la rapidité est tout simplement inexistante.

Mais il existe des solutions. Ils sont connus depuis longtemps.

Comment obtenir une accélération ?

La solution la plus simple, la moins chère et la mieux testée est la mise en cache du bytecode. Au lieu de passer par la phase d'analyse, nous mettons simplement en cache notre bytecode. Il existe des extensions spéciales pour cela - elles sont bien connues de tous ceux qui ont travaillé avec PHP - ce sont APC, eAccelerator, Xcache, etc. Zend Engine exécute simplement le bytecode.

La deuxième option est le profilage du code, identifiant les goulots d'étranglement. Nous pouvons réécrire quelque chose sous forme d'extensions PHP (ce sera une extension en C/C++), le compiler et l'utiliser comme modules.

La troisième option est plus globale : oubliez PHP et réécrivez tout. En général, cette option a droit à la vie, mais uniquement dans le cas où il n'y a pas assez de code PHP. Dans les grands et grands projets (ou qui existent depuis assez longtemps), une grande partie s'accumule généralement et il faudra beaucoup de temps pour tout réécrire. Les exigences commerciales ne vous permettront pas de le faire. En général, écrire quelque chose en PHP, par exemple pour un serveur front-end, ne prend pas trop de temps, car c'est un langage simple. Il vous permet de faire rapidement des choses qui prennent plus de temps dans les langages de bas niveau.

Il existe une option alternative, qui s'est récemment répandue, et qui consiste à compiler PHP quelque part, en quelque chose de plus rapide.

Compilons quelque chose ?

Par le mot « compilation », j'entendrai la traduction du code de script PHP en autre chose, en un autre code.

Dans ce cas il peut être de deux types.

Le code natif est une sorte de fichier binaire pouvant être exécuté sur une machine physique.

Code non natif. Vous pouvez compiler du bytecode qui peut être exécuté sur une autre machine virtuelle, par exemple sur la JVM.

Comment compiler du code natif à partir de PHP ?

Compilateur Roadsend. Sa suite est Raven. Il existe également PHC (il s'agit d'un compilateur PHP Open Source). Récemment, HipHop (Facebook) est également apparu.

Je vais donner un bref aperçu de ce qui peut être fait pour le code non natif. Autant que je sache, il existe 3 options de travail. Il s'agit de la génération de bytecode pour Java et de la génération de bytecode pour .Net : Quercus, Project Zero, Phalanger. Je n'envisagerai pas la compilation en code non natif, car nous ne l'utilisons pas. Revenons à la compilation en code natif.

À mon avis, le compilateur le plus ancien est Roadsend. Son développement a commencé il y a longtemps, en 2002. Il s'agissait à l'origine d'une application commerciale. Il a été fermé, ce n'est qu'en 2007 qu'il a été publié en Open Source. Il existe un schéma de compilation très complexe : un certain compilateur Bigloo est utilisé pour le langage Scheme, après quoi du code natif est généré. Ce compilateur n'utilise pas le Zend Engine.

Nous pouvons soit générer un binaire exécutable séparé, soit générer un module pour Apache. Il est également possible de générer un binaire qui fonctionnera comme serveur web. Mais ça ne marche pas. Je ne sais pas pourquoi, mais ça ne marche pas du tout pour moi.

Pour autant que je sache, les travaux sur Roadsend ne sont pas en cours actuellement. Il a évolué vers le projet Raven, entièrement réécrit en C++. En tant que compilateur, il utilise LLVM pour générer du code.

Pour le moment, tout semble très prometteur.

Mais il est encore en construction. Même dans la documentation, il y a des indications selon lesquelles nous ne générerons pas de binaires. Attendez.

Les choses seraient tristes si nous n'avions pas de soins de santé primaires. Il s'agit d'un compilateur OpenSource. Il est développé depuis 2005. Un de ses inconvénients : il utilise SAPI intégré. Nous n'abandonnons pas la machine Java, le Zend Engine. Essentiellement, il traduit le code PHP en code de module d'extension PHP. Après cela, il compile, mais le processus d'exécution, encore une fois, implique le Zend Engine.

Exemple d'utilisation de PHC

Très similaire à la façon dont nous travaillons, par exemple, avec les compilateurs conventionnels, gcc. Le premier montre qu’il existe un binaire, on peut aussi simplement générer le code C. Étant donné que le même gcc est utilisé en interne après avoir généré ce code, nous pouvons utiliser les indicateurs destinés à l'optimisation et à d'autres choses.

Nous parlions d'une application qui s'exécute en ligne de commande.

Pour lancer une application web il faut réaliser plusieurs étapes, c’est assez complexe. Vous devez d’abord générer une extension, puis compiler le code, puis le connecter d’une manière ou d’une autre (dynamiquement ou statiquement).

Principaux avantages des SSP

Essentiellement, nous utilisons le même PHP, nous sommes entièrement compatibles. Toutes les autres extensions sont prises en charge. Nous utilisons tout ce que nous avons compilé. Assez bonne documentation.

À propos, l'un des avantages supplémentaires de PHC est que vous pouvez générer le travail XML de notre script en fonction de la manière dont XML est construit, ce qui peut parfois être utile.

Inconvénients

À mon avis, il s'agit d'un binaire inférieur, car il dépend toujours de Zend Engine. Il existe également une certaine complexité en termes de connexion de projets Web.

À propos de l'essentiel

Ce rapport n'aurait probablement pas eu lieu si HipHop, une solution de Facebook, n'était pas apparu. Ses créateurs ont également accumulé une grande quantité de code PHP et ont longtemps réfléchi à quoi en faire.

Si je comprends bien, après que les options permettant de tout réécrire ont été rejetées, il a été décidé d'écrire une sorte de traducteur (dans ce cas en code C++). Le projet est relativement jeune ; il n'a été officiellement publié qu'en février de cette année. Le code PHP est traduit en code C++ puis généré à l'aide d'outils standards sur votre système d'exploitation. Cependant, pour l'instant, seul le système d'exploitation Linux est pris en charge.

Hier encore, j'ai interrogé un représentant de Facebook sur cette décision. Il a déclaré qu'actuellement, 100 % du code PHP est compilé via HipHop. Le code ne fonctionne pas sous sa forme pure via l'interpréteur PHP. Encore une fois, les créateurs ont annoncé une réduction significative de la charge du processeur.

Fonctionnalité de base de HipHop

Il génère directement le binaire lui-même, qui peut être exécuté sur la ligne de commande. Il existe une telle option pour le lancer en tant que serveur Web de streaming. Il existe également un débogueur intégré séparé. Il peut déboguer des scripts localement et à distance (il fonctionnera comme serveur).

Le processus d’assemblage n’est pas trivial. Il existe une description, mais elle n'est pas collectée partout. Pour le moment, comme je l'ai dit, tout est assemblé pour Linux, et au départ tout était « taillé sur mesure » pour 64 bits. Bien que 32 bits soient désormais pris en charge expérimentalement. Mais j'ai réussi à l'assembler et à le patcher un peu - en général, il a fait tout cela, car il n'est pas assemblé par défaut.

De plus, ils ont leurs propres versions de libcore et, à mon avis, quelques bibliothèques doivent également être corrigées. En général, le processus d'assemblage n'est pas si simple.

En sortie après assemblage, nous recevons un certain fichier hpp, qui est un traducteur de notre code PHP en C++. Si l’on regarde les drapeaux, il y en a beaucoup. J'ai mis en évidence ici quelques éléments de base dont vous pourriez avoir besoin.

On peut utiliser un fichier au format HDF comme fichier de configuration (config), spécifiant diverses directives. Nous pouvons y définir le niveau d'erreur et d'autres choses (HDF est tout ce qui est disponible sous une forme structurée). Nous pouvons également extraire la configuration elle-même de la base de données ou l'utiliser directement sur la ligne de commande.

Nous définissons le niveau de journalisation lors de la compilation : afficher toutes les erreurs ou afficher également des avertissements, des informations supplémentaires, ou généralement conserver un journal complet de tout ce qui se passe.

Une directive très utile est input_list=FILE, qui nous permet de spécifier une liste de scripts que nous souhaitons compiler. Il convient également de mentionner une directive telle que lazy-bind. Nous pouvons spécifier tous les fichiers du projet – ceux qui seront compilés.

Exemple d'exécution d'une compilation de script PHP

Le troisième niveau de journalisation a été installé, il y a des informations assez générales sur le temps, vous pouvez voir combien de temps cela a pris. En fait, le scénario est assez simple. C'est l'habituel "Hello, World", je viens de prendre une capture d'écran.

Le fichier le plus lourd est notre binaire « programme », sa taille est de 28 Mo. Essentiellement, notre "Hello, World" pèse 28 Mo. Je voulais noter qu'en plus de la ligne standard "Echo "Hello, World!", ce binaire comprend bien plus encore. Il s'agit d'un serveur Web à part entière, d'un serveur d'administration à part entière.

Que faisons-nous ?

Nous avons « Hello… » en C++, qui exécute une fonction composée d'une seule ligne « echo » Hello, World ». De plus, de nombreux éléments tiers sont chargés. Comme nous pouvons le voir, il s'agit d'un fichier à part entière. en C++.

C'est le programme résultant. Il contient déjà pas mal de touches différentes pour différentes configurations, mais je n'en mentionnerai que quelques-unes.

C'est --mode, c'est le mode de lancement de notre programme. Nous pouvons l'exécuter soit directement (à partir de la ligne de commande), soit en mode serveur Web ou démon à part entière. Il existe quelques options supplémentaires, mais elles sont sans importance.

config est utilisé dans le même format. Je n'ai pas donné de directives car il y en a beaucoup. HipHop est livré avec de la documentation. Ce n'est pas sur le site wiki, mais une documentation est fournie avec la distribution, où tout est clairement décrit. Je ne m'attendais même pas à ce que la description soit aussi détaillée. Cela vous permet de configurer la solution de manière assez flexible.

Pour fonctionner en mode serveur, nous pouvons spécifier le port. Pour l'administration, un port séparé est utilisé, où vous pouvez envoyer certaines requêtes qui vous permettent de gérer le serveur. Si nous avons un serveur de débogage en cours d'exécution, nous indiquons l'hôte et le port sur lesquels nous allons « nous lier » pour le débogage.

Exemple de lancement

Par exemple, nous avons spécifié le port 9999 pour la diffusion En effectuant de simples requêtes http, nous pouvons soit recevoir des statistiques, soit gérer le serveur d'une manière ou d'une autre, soit obtenir des informations supplémentaires. En général, c'est très pratique.

Option pour obtenir des informations sur l'état

Il est possible de recevoir l'état du serveur défini dans différents formats intégrés (xml, json, html). Essentiellement, des informations sont fournies sur le processus maître du serveur lui-même et sur les gestionnaires - les threads qui traitent les demandes.

Statistiques supplémentaires

En fait, de nombreuses statistiques sont fournies. Parce que HipHop fonctionne nativement avec Memcache et SQL sous la forme de MySQL, il fournit des informations détaillées sur toutes les opérations effectuées avec lui.

Statistiques complètes de la mémoire

Il y a une fonctionnalité très utile ici - les statistiques d'application. En utilisant les fonctions supplémentaires de HipHop lui-même en PHP, nous pouvons écrire des statistiques dans nos scripts, que nous recevons ensuite via un accès régulier à http.

Débogage

Comme je l'ai déjà dit, il est possible d'utiliser le "debug" intégré pour déboguer des scripts. C'est très pratique car l'interpréteur hppi fonctionne de la même manière que celui que nous avons compilé. Il existe une différence dans le « comportement » des scripts lorsqu’ils sont exécutés en PHP standard et lorsqu’ils utilisent certaines données compilées. Pour déboguer ce qui est compilé, Facebook a écrit un interpréteur distinct.

Dans le premier cas, nous exécutons le code avec le commutateur « -f » et voyons comment le fichier se comporte ; toutes les sorties vont vers la sortie standard. Ou nous pouvons l'exécuter en mode débogage et accéder au débogueur interactif. Il est très similaire au GDB standard : vous pouvez également définir des points d'arrêt, exécuter, saisir des valeurs de variables, suivre, etc.

Une des fonctionnalités supplémentaires

Nous avons un programme qui s'est avéré après compilation. Il peut être utilisé comme serveur RPC. Nous exécutons des requêtes via http et en appelant la fonction params, nous pouvons transmettre un paramètre sous forme de tableau json ou de paramètre distinct. Nous aurons renvoyé json, qui renvoie les résultats de ces fonctions. C'est très pratique : les fonctionnalités nécessaires sont déjà intégrées dès le début.

Inconvénients du hip-hop

Actuellement, HipHop ne prend pas en charge les constructions et fonctions de langage telles que eval(), create_function() et preg_replace() avec /e, bien qu'elles soient toutes analogues à eval(). Cependant, dans les dernières versions, à mon avis, vous pouvez toujours activer eval() via config. Mais cela n'est pas recommandé. En général, eval() est mauvais à utiliser.

Les principaux avantages du HipHop

Bien entendu, le principal avantage est le support de Facebook. Cela fonctionne et est développé assez activement. Une communauté de développeurs émerge autour de ce projet. Une toute nouvelle implémentation PHP a été écrite.

Comme je l’ai déjà dit, l’avantage est que du code natif est généré. Une augmentation des performances est revendiquée en réduisant les coûts de charge du processeur (les tests le confirment).

Sa configuration est assez flexible. J'ai été agréablement surpris de constater qu'il existe de nombreuses options de personnalisation. Je pense que cela est dû au fait que le projet fonctionne réellement. Tout ce qui est utilisé est incrémenté.

Comme je l'ai déjà mentionné, HipHop offre de nombreuses fonctionnalités supplémentaires. Ceux-ci incluent l'utilisation comme serveur RPC, l'administration, diverses statistiques et bien plus encore. À propos, il existe également une API pour travailler avec d'autres langages.

Une assez bonne documentation a été écrite pour cette solution. Autre avantage : il s'agit d'une solution effectivement prête à être utilisée en production (exemple : Facebook).

Inconvénients

Le principal inconvénient est qu'à l'heure actuelle, un nombre plutôt limité de modules sont pris en charge. Par exemple, lorsque nous travaillons avec une base de données, nous ne pouvons utiliser que des fonctions permettant de travailler avec MySQL. Il n'y a pas de support PostgreSQL ici.

Il y a aussi la complexité du montage, que j'ai déjà évoquée. Il y a des problèmes avec la construction sur des systèmes 32 bits. Mais je pense que cela sera bientôt corrigé. Pour l'instant, seule la compilation à partir de PHP 5.2 est utilisée. La version 5.3 n'est pas encore prise en charge, mais le sera comme promis.

Que ne faut-il pas attendre de la compilation en général et du HipHop en particulier ?

La compilation n'accélérera en aucun cas vos requêtes SQL lentes dans la base de données. Si le goulot d’étranglement est la base de données, alors compilez-la ou ne la compilez pas, cela ne servira à rien.

La compilation n'accélère pas le chargement statique, mais uniquement le chargement dynamique. Cela rend le débogage beaucoup plus difficile. Beaucoup de gens sont probablement habitués au fait que tout est assez simple à déboguer en PHP. Cela n'arrivera plus lors de la compilation. Bien que, comme je l'ai noté, Facebook ait rendu ce processus aussi simple que possible, sans cela, il serait encore plus difficile de le compiler à chaque fois.

Ne vous attendez pas à ce que ce soit une sorte de « solution miracle » qui résoudra tous vos problèmes. En fait, la compilation résout un éventail assez restreint de problèmes. Si tel est le cas, cela peut aider.

Quels problèmes la compilation résout-elle ?

Cela réduit la charge sur le processeur, car lorsque vous travaillez activement avec PHP et un grand nombre de requêtes, la charge augmente de manière assez significative. Bien sûr, j'aimerais effectuer quelques tests.

Essai

Le premier test (le plus simple) est une opération assez coûteuse et assez longue à réaliser. Lors des tests, j'ai essayé de m'abstraire et de ne pas faire de requêtes en utilisant une ressource externe.

La charge incombe entièrement au processeur. Le test a montré que HipHop « a gagné » contre tout le monde : il fonctionne presque une fois et demie plus vite que le compilateur PHP standard. PHC a réussi ce test très lentement.

Pour le deuxième test de performances, j'ai utilisé le script PHP officiel, téléchargeable depuis SVN. Il exécute un certain nombre de fonctions qui effectuent le tri, l'affectation, la sommation - des opérations assez coûteuses d'un point de vue mathématique.

Le HipHop était encore en avance. De plus, avec PHP standard, le décalage horaire est d'environ 3 fois. PHC a obtenu de meilleurs résultats ici, mais était environ deux fois moins mauvais que HipHop.

PHP est principalement utilisé pour les threads qui gèrent les requêtes http – cela vaut la peine de garder à l’esprit.

Plusieurs configurations standards (Apache avec PHP, Nginx avec fpm-php et plug-in APC pour la mise en cache du code). Comme cinquième option - HipHop.

Pour être honnête, j'ai effectué les tests non pas sur le serveur, mais sur un ordinateur portable. Bien entendu, les chiffres peuvent ne pas correspondre entièrement à la réalité, mais dans ce cas, les résultats sont normaux. Il convient de noter qu'à mesure que la charge augmente, le nombre de requêtes et le nombre total de requêtes augmentent simultanément. Vient ensuite le RPS. Nous avons testé une page standard qui comprend 10 inclusions simples. Essentiellement, il s’agit de tester PHP en tant qu’interpréteur.

Question du public : Quels sont les nombres dans la cellule - secondes ?

Alexeï Romanenko : C'est des fps.

Ici, nous pouvons conclure qu'à mesure que le nombre de requêtes simultanées augmente, HipHop se comporte très bien.

On voit que l’utilisation d’APC est une pratique courante. Cela montre qu'il ajoute, par exemple, comme Apache, une amélioration des performances d'environ 2 fois. Cela arrive également avec Nginx. Mais le fait que Nginx soit lent ne signifie pas que ce package est pire. Juste un test spécifique. Si nous testons vraiment ici, alors Apache « mourra » sur les requêtes lentes.

Nous voulons probablement comprendre si nous en avons besoin ou non.

Quand faut-il penser à la compilation ?

Très probablement, cela est nécessaire lorsque nous constatons que notre goulot d'étranglement est le processeur. Si nous utilisons PHP comme interpréteur standard, cela vaut probablement la peine de considérer qu'une partie du projet peut peut-être être compilée.

Dans certains cas où votre application a besoin d’autonomie pour fonctionner, il est peu probable que cette méthode soit adaptée.

Réduire le nombre de serveurs. Lorsqu'il y a beaucoup de serveurs, alors en réduisant la productivité de 2 fois, grosso modo, on réduit également le nombre de moitié. Lorsqu’il s’agit d’un seul serveur, cela n’a aucun sens, mais lorsqu’il y en a 100 à 200, cela a probablement du sens.

La principale raison pour laquelle Facebook a commencé à utiliser HipHop est la présence de grandes quantités de code PHP qu'il n'y a aucun moyen de réécrire (ou il n'y en a pas, ou c'est tout simplement cher). Augmenter la productivité de 2 fois, c’est déjà bien.

Probablement tout. J'attends des questions.

Questions et réponses

Question du public : Bonjour. S'il vous plaît dites-moi si vous avez d'autres exemples d'implémentations Hiphop réussies, en plus de Facebook. Souhaitez-vous transférer le site Web de RBC, par exemple, vers HipHop ? Alexeï Romanenko : Je vais commencer par le deuxième. Le site Web de RBC est difficile à traduire. Concernant une mise en œuvre réussie. J'ai compilé PHP Unit moi-même, il a été compilé avec succès. De plus, pour autant que je sache, la carte PHP Bunty se compile avec succès. En fait, un certain nombre d’organisations utilisent déjà la compilation. D'autres tests montreront dans quelle mesure l'utilisation de ce projet sera justifiée. Question du public : Pouvez-vous donner un exemple d’organisation qui l’utilise ? Alexeï Romanenko : Honnêtement, je ne vous le dirai pas maintenant, mais c’est l’Occident. À ma connaissance, personne ne l'utilise ici. Question du public : Quelle est la différence au moment de l'exécution, autre que le manque de prise en charge de certaines des fonctionnalités que vous avez mentionnées. Dans quelle mesure est-il dangereux de traduire un projet « en direct » ? Alexeï Romanenko : La différence est que tout programme compilé peut échouer. Peut-être que certains problèmes apparaîtront qui n'ont pas encore été identifiés. En fait, il existe un certain nombre de différences dans le « comportement » de PHP lui-même. Je ne les ai pas inclus car des informations plus détaillées peuvent être trouvées dans la documentation. L'équipe Facebook a écrit son propre interprète, qui est en fait équivalent à 99,9% à celui qui fonctionnera sous forme compilée. Il est préférable de tester votre code non pas avec un interpréteur PHP standard, mais, comme je l'ai dit, avec hppi pour PHP.

Presque tous les développeurs sont tôt ou tard confrontés à la nécessité d'exécuter ou de vérifier rapidement du code, mais tout le monde ne sait pas que pour une tâche aussi simple, il n'est pas du tout nécessaire d'exécuter des IDE de bureau lourds ou des compilateurs d'applications. Il suffit d'utiliser des outils en ligne qui vous permettent de tout faire beaucoup plus rapidement : Ctrl+C, Ctrl+V, Run, whack - et la sortie du programme est déjà sous vos yeux rougeâtres.

Nous avons sélectionné les meilleurs compilateurs en ligne : certains d'entre eux sont assez universels, d'autres sont adaptés à des tâches strictement définies. En tout cas, ils ne seront pas superflus.

Codage

Koding.com n'est pas un compilateur en ligne au sens traditionnel du terme. Chaque utilisateur du service peut créer plusieurs machines virtuelles à part entière exécutant Ubuntu 14.04 dans le cloud, sur lesquelles il peut faire ce qu'il veut, y compris compiler du code. Toutes les langues populaires sont prises en charge par défaut, mais vous pouvez facilement ajouter la vôtre.

En plus du panneau de contrôle de votre serveur, un IDE pratique et une fenêtre de terminal sont disponibles dans l'interface. Koding est l’outil le plus universel ; ci-dessous, nous examinerons des options plus simples et plus spécialisées.

IdéeOne

IdeOne est un compilateur et un outil de débogage en ligne qui vous permet d'exécuter du code dans plus de 60 langages de programmation et leurs versions spécifiques directement dans le navigateur.

Pour ceux qui n'ont pas de petite amie, les créateurs ont prévu une compilation de code dans le langage Brainfuck.

JDoodle

Un autre compilateur en ligne qui prend en charge de nombreux langages, dont certains que vous ne trouverez pas dans de nombreux autres compilateurs en ligne. Une fonctionnalité intéressante de JDoodle est la possibilité de collaborer : il suffit d'envoyer un lien vers votre session en cours et de générer des bugs deux fois plus vite !

jsFiddle

Ne vous laissez pas tromper par le nom : jsFiddle n'est pas uniquement conçu pour JavaScript. Cet éditeur frontal en ligne vous permet de tester n'importe quelle combinaison de JavaScript, HTML et CSS. Bien sûr, divers frameworks sont pris en charge, par exemple jQuery, Vue, React, TypeScript, ainsi que des préprocesseurs CSS comme SCSS. Pour plus de commodité, vous pouvez sélectionner une combinaison de touches dans votre éditeur préféré. C'est vrai, seulement si votre éditeur préféré est Vim, Emacs ou Sublime Text.

CodePad

CodePad est un service minimaliste dans lequel vous pouvez stocker du code, le partager et l'exécuter avec la sortie ultérieure des résultats de son exécution. Il existe plusieurs des langages les plus courants parmi lesquels choisir, mais, malheureusement, sans le choix de versions spécifiques d'interprètes ou de compilateurs.

Son principal avantage est sa simplicité et sa facilité : le site fonctionnera rapidement même avec une connexion Internet lente. La connexion automatique des en-têtes standards est fournie, ainsi que l'intégration avec Vim ou Emacs.

L'un des inconvénients est l'absence totale de coloration syntaxique lors de la saisie du code dans le formulaire. Cependant, lors de la visualisation d'un enregistrement déjà enregistré, le rétroéclairage est présent.

GodBolt du CCG

GCC GodBolt est un compilateur C++ interactif. Je suis entré dans cette collection parce qu'elle possède une interface simple, ainsi qu'un grand nombre de paramètres, y compris des options qui peuvent être ajustées à l'aide de touches.

Il existe de nombreuses versions de compilateur parmi lesquelles choisir, y compris les dernières. L'une des fonctionnalités intéressantes est la traduction instantanée du code du programme en langage assembleur.