capacité d'un fichier php

Pour faire très court ce n'est pas du côté du temps de génération de l'opcode qu'il faut chercher de l'optimisation.
Mais plutôt du côté du temps de chargement des fichiers, en gros le système de fichier est au cœur du problème.
Comme précédemment dit on n'inclut pas 100 fichiers si on n'en utilise que 3. Tout comme on ne fait pas un fichier regroupant 1000 fonctions si on sait qu'en général seules 3 sont utilisées.

Je suis content de voir que certaines personnes s'intéressent au fonctionnement de PHP, c'est tellement rare. :)

Salam (salut); donc faut éviter le méga-fichier sauf que le problème se pose pour la limite en fonction du contenu et le type d'instruction

Citation:

---

Stealth36 "mais ce qu'il y'a dedans..."

---

!!!!
fonctionnement de l’interpréteur :

Citation:

---

le fichier passe par un lexer (analyseur de syntaxe),
Convertit le fichier en unités de code compréhensibles pour le processeur,
Ce flux d'unités est ensuite traité par le parser,
le parser créé le code intermédiaire qui sera exécuté pour le Zend Engine,
Ce dernier agit comme une machine virtuelle, qui combine les différentes unités sous forme d'opcodes, et les exécute un à un.

---

a cet étape ( en rouge) la conversion se fait par rapport au bloc du code transcrit sur le fichier ou selon langage du processeur ?
a cet étape je crois qu'il y'a un système d'indexation afin de permettre de rassemblé le tout après.

Non pas d'indexation à ce niveau là, il ne fait que traduire un langage dans un autre.

je crois que le sujet dépasse mes compétences ; voila je me limite juste a ce qui suit:
Comment l’interpréteur gère les unités de code contenues dans un fichier en include par rapport au fichier principal ?
Est ce que sont classés dans un tableau avec des identifiants ou autre afin de les appelés rapidement ( le chemin le plus court) a l'endroit voulu?

Il ne faut pas penser en terme d'include car un include c'est un copier/coller de code. Au final c'est comme s'il n'y avait qu'un seul fichier avec tout dedans. ;)

Oui ;

Citation:

---

Comment l’interpréteur gère les unités de code contenues dans un fichier en include par rapport au fichier principal ?

---

donc l’interpréteur lit le contenu en trois lectures:

1. Lecture lexicale ( montage d'un arbre de structuration de la lecture et de l'exécution du code) ,
2. Analyse sémantique ,
3. Et la dernière pour convertir le code dans un langage intermédiaire,

a la fin l’interpréteur va lire le opcode et effectué les opérations selon u ordre.
la même opération est exécutée pour chaque appel ou chaque internaute (nécessité d'un outil de mise en cache).
donc en résumé y'a u arbre logique de lecture et d’exécution du code cela dit un certain algorithme.

Salam ; sans entré dans les détaille peut-on dire que chaque unité de code est indexé pour être appelée (exécuté) plus tard a l'endroit précis soit dans le même ou autre fichier sans faire une relecture du opcode ? :no:

Citation:

---

Envoyé par redoran

Salam ; sans entré dans les détaille peut-on dire que chaque unité de code est indexé pour être appelée (exécuté) plus tard a l'endroit précis soit dans le même ou autre fichier sans faire une relecture du opcode ? :no:

---

[ame="http://www.slideshare.net/jpauli/anatomie-et-performances-de-php"]Anatomie et performances de php@@AMEPARAM@@ssplayer2.swf?doc=performancesphp-afup-2012-120605080326-phpapp01&stripped_title=anatomie-et-performances-de-php@@AMEPARAM@@performancesphp-afup-2012-120605080326-phpapp01@@AMEPARAM@@anatomie-et-performances-de-php[/ame]

Salam (salut) , merci stealth35 pour ce lien qui est vraiment riche dommage qu'il n'est pas téléchargeable. :?
y'a un énorme travail qui se fait avant la génération du opcode.
Le opcode est traité par un gestionnaire "zend_vm_handler" d'une manière linéaire avec possibilité en boucle.
devant cette complexité je rend les armes et je me contente de resté aux abord du compréhensible bravo pour l'auteur :ccool:

Demande à Julien de t'envoyer le fichier si ça t'intéresse

Salam (salut); j'ai dit un jour

Citation:

---

devant cette complexité je rend les armes et je me contente de resté aux abord du compréhensible...

---

:roll:
je reviens a ma question , sincèrement j'ai lu et relut le document:
le opcode est généré pour évité la relecture du fichier.
maintenant a partir du opcode comment les unités de code son sélectionnés pour être exécutées ?
exemple:
si l'opcode contiens un présentation d'unités de code allant de 01 a 50 unités.
et le programme a besoin de l'unité 20 pour être exécutée dans le fichier X , là est ce que il va relire tous l'opcode ou tous simplement y a un système qui permet d'aller directement a l'unité 20 ? :triste:

Citation:

---

Envoyé par redoran

le opcode est généré pour évité la relecture du fichier.

---

non il est lu et crée a chaque fois

Citation:

---

Envoyé par redoran

maintenant a partir du opcode comment les unités de code son sélectionnés pour être exécutées ?
exemple:
si l'opcode contiens un présentation d'unités de code allant de 01 a 50 unités.
et le programme a besoin de l'unité 20 pour être exécutée dans le fichier X , là est ce que il va relire tous l'opcode ou tous simplement y a un système qui permet d'aller directement a l'unité 20 ? :triste:

---

réponse au dessus, a chaque fois que tu lances le fichier tu repart a zéro, mais je te l'ai déjà dis, si tu veux éviter de reparler les fichier met un cache d'opcode comme APC

Salam ; avec un cache d'opcode comme APC , Comment ce dernier va traité cette problématique :
si l'opcode contiens un présentation d'unités de code allant de 01 a 50 unités.
et le programme a besoin de l'unité 20 pour être exécutée dans le fichier X .

1. Faire une relecture ?
2. Garder en mémoire la liaison entre l'unité 20 du fichier parmi les 50 et le point d’exécution de l'unité 20 dans le fichier X?

Salam ; voila je vais creusé un peu plus aux risques et périls :bug:
Les OPCodes sont des structures de données C,
Sa ne ressemble pas au opcode hexadécimal des consoles de jeux,
S’exécute sur 8 bits ? 32 Bits ? 64 Bits?
Est ce que il établi une table de correspondance ?
Si c'est le cas normalement y a un algorithme qui permet de retrouver facilement l'unité de code concernée dans le fichier X? :salive:

Citation:

---

Envoyé par redoran

Salam ; voila je vais creusé un peu plus aux risques et périls :bug:
Les OPCodes sont des structures de données C,
Sa ne ressemble pas au opcode hexadécimal des consoles de jeux,
S’exécute sur 8 bits ? 32 Bits ? 64 Bits?
Est ce que il établi une table de correspondance ?
Si c'est le cas normalement y a un algorithme qui permet de retrouver facilement l'unité de code concernée dans le fichier X? :salive:

---

Qu'est ce t'appelle une table de correspondance et unité de code ?
Pour le reste c'est une VM
T'as installé VLD ?

Citation:

---

Qu'est ce t'appelle une table de correspondance

---

table a titre d'exemple ( en tréalité je ne c'est pas comment elle est constituée!!!) :

index || unité de code
0 || code 1
1 || code 2

Unité de code:
instruction,
fonction....ect

Citation:

---

T'as installé VLD ?

---

non mais je voulais simplement comprendre le système d'appel d'unité de code selon le besoin.

Install le et tu comprendras

Salam ; l'aventure continue a la recherche de :roll:
les opcodes générés sont écrits en verticales ( du haut vers le bas) , donc un sens d'exécution unidirectionnelle avec éventuellement des boucles (selon le code PHP) , tous cela dépend de l'assembleur non!!!
donc ce schéma renvoi a la gestion des piles....
ici on va passé a la gestion des nœuds.... toute un système olala :aie:
je crois que cette question relève des compétences de ceux qui ont programmé avec le langage C!!!!

Y'a pas de boucle en assembleur y'a que des sauts, mais qu'est ce tu cherches à savoir vraiment en demandant tout ça ?

Hello,

Citation:

---

Envoyé par redoran

cas pratique: le fichier tab.php appel fichier sisam.php, interprétation du code avec envoi de résultat ( application de l'instruction 25 sur les 500 instructions). le deuxième appel , l’interpréteur refais la même lecture et envoi le résultat ( application de l'instruction 25 sur les 500 instructions). donc y'a perte de temps en ms. ce qui j'arrive pas a comprendre comment il sait le chemin le plus court de l'instruction 25 parmi les 500 ( exemple champs indexé dans une table suit un algorithme bien définie).

---

Tes questions sont légitimes et pour pouvoir te répondre de manière certaine, il faudrait explorer les spécifications de Zend, voire son code source.

Cela dit, tu as globalement compris le principe… qui n'est d'ailleurs pas récent ! Tous les BASIC des années 1980, embarqués en ROM sur les ordinateurs huit-bits de l'époque et sur les tout premiers PC, fonctionnaient de la même manière et « crunchaient » le programme saisi en une sorte de bytecode, pour les raisons que tu exposes aujourd'hui et parce que la mémoire était très limitée. En outre, faire du parsing d'un code ASCII était coûteux en temps CPU, même si c'est quasiment transparent aujourd'hui.

Dans le cas du PHP, cela dit, le code est compilé à la volée, au moins la première fois, puisque le code est en principe inclus au sein d'une page HTML, qui passe donc d'abord par ton serveur Web qui, lorsqu'il reconnaît les balises « <?php ?> », en transmet le contenu à l'interpréteur. D'autre part, si on fait abstraction du cas du goto et de l'inclusion multiple d'un même fichier (soit un copier-coller déguisé), le seul moyen de faire un saut vers une partie arbitraire du code entier est d'appeler une fonction.

On peut donc facilement en déduire que le code produit :

— Est effectivement indexé ;
— Qu'il ne l'est qu'aux endroits soit explicitement définis par la syntaxe du code (dans une boucle, par exemple), soit au point d'entrée d'une fonction chaque fois que l'une d'elle est rencontrée ;

Ensuite, le reste relève de l'optimisation du moteur proprement dit. Par exemple, si le moteur rencontre un appel à une fonction qu'il ne connait pas encore, il peut choisir de laisser l'appel « en blanc » jusqu'à la fin du fichier en cours pour voir s'il la trouve. On peut facilement mettre cela en évidence par le code suivant :

Code:

---

1 2 3 4 5 6 7

# Fichier helloworld.php   <?php   function helloworld() { echo "<p>Hello, world!</p>\n"; }   ?>

---

… puis :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

# Fichier index.php version 1 <html> <head> <title>Hello</title> </head> <body> <p>Bonjour</p> <?php include "helloworld.php"; # include avant l'appel helloworld(); ?> <body> </html>

---

… et :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

# Fichier index.php version 2 <html> <head> <title>Hello</title> </head> <body> <p>Bonjour</p> <?php helloworld(); include "helloworld.php"; #include après l'appel ?> <body> </html>

---

Sur ma machine (Apache 2 + PHP 5.3.13), la première version de « index.php » affiche bien « hello, world! » mais pas la seconde, ce qui tend à montrer que l'interpréteur limite la recherche au fichier courant et ne la propage pas en cascade à travers un include.

Il n'y a donc rien de compilé « a priori » si on ne lui dit pas explicitement de le faire.