Bootstrap et performances

**stealth35** · 19/01/2012, 17h15

Autant tout mettre dans un Phar compressé.

**rawsrc** · 19/01/2012, 17h25

Envoyé par stealth35

Autant tout mettre dans un Phar compressé.

C'est pas équivalent dans le mesure ou tu devras décompresser l'archive avant de parser quand même son contenu. En minifiant, tu évites la décompression et tu ne fais que le parsage.
Ce qui aurait été très intéressant par contre c'est d'avoir la possibilité de stocker le résultat d'un fichier parsé et de le charger tel quel (un peu comme si le résultat du fichier parsé était assimilé à un fichier compilé ou un truc du genre).

**Benjamin Delespierre** · 19/01/2012, 17h26

Envoyé par grunk

Le temps mis part PDO est assez étonnant. Voila ce que ça donne chez moi , sachant que PDO est en plus instancié par Zend_Db :

En gros 26 ms pour l'instanciation et 4 requêtes , d'où mon étonnement pour tes 50 ms.
Je viens de faire un profiling chez moi et très clairement ce qui me prend le plus de temps c'est le moteur de template (twig) et du coup je tourne également à une moyenne de 300 ms par page. avec un cache sur le template je suis en moyenne à 80ms.

Bon après si tes test on été fait sur une machine peut puissante ou php 5.2 ça peut expliquer cette différence.

Effectivement j'aurais dû préciser:

Environement Windows XP (SP3)
MySQL 5.1
PHP 5.2 (avec Xdebug + Profiling)
Dual Core à 2Ghz (occupé à 15% par la VM et par FireFox )

J'obtiens de bien meilleures performances avec ma VM sous linux

Il gèlera en enfer avant que je déploie en prod sous Windows

Et puis je passe par la loopback 'localhost' au lieu de mettre '127.0.0.1' comme une andouille...

Je vais te faciliter le travail, j'ai changé la licence en LGPL (donc tu peux rester relax) et pour l'adaptation en PHP 5.2, il te suffit de commenter dans le tableau $noSpaces le T_NS_SEPARATOR qui correspond au séparateur de namespace (PHP 5.3+).
Normalement tout devrait rouler pour ta version.

Merci, c'est sympa

on gagne pas grand chose par rapport a un php_strip_whitespace

Stealth, je me suis toujours demandé d'où te venait cette aptitude à sortir de ton chapeau toutes les fonctions du manuel

Tu te les ai faites graver dans le cerveau ou quoi ?

Autant tout mettre dans un Phar compressé.

Je suis pas sûr que ça nous fasse gagner en vitesse...

**Benjamin Delespierre** · 19/01/2012, 17h28

Envoyé par rawsrc

C'est pas équivalent dans le mesure ou tu devras décompresser l'archive avant de parser quand même son contenu. En minifiant, tu évites la décompression et tu ne fais que le parsage.
Ce qui aurait été très intéressant par contre c'est d'avoir la possibilité de stocker le résultat d'un fichier parsé et de le charger tel quel (un peu comme si le résultat du fichier parsé était assimilé à un fichier compilé ou un truc du genre).

Pas obligatoirement, avec l'extension PHAR tu peux tout à fait faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 include 'phar:///path/to/myphar.phar/file.php';

**stealth35** · 19/01/2012, 17h50

Envoyé par rawsrc

C'est pas équivalent dans le mesure ou tu devras décompresser l'archive avant de parser quand même son contenu. En minifiant, tu évites la décompression et tu ne fais que le parsage.
Ce qui aurait été très intéressant par contre c'est d'avoir la possibilité de stocker le résultat d'un fichier parsé et de le charger tel quel (un peu comme si le résultat du fichier parsé était assimilé à un fichier compilé ou un truc du genre).

le require_once, décompresse l'archive en direct, le process de tokeninzation n'est pas calculable avec script PHP,
mais j'avoue que t'as quand même un bon gain avec ton code

sur ça classe : IniConfiguration

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
file_get_contents    : 414
php_strip_whitespace : 399
PhpMinifier::minify  : 299

pour le reste APC est la pour ça puisqu’il fournit l'opcode, tu zappes donc deux étapes

**rawsrc** · 19/01/2012, 17h53

Je suis bien d'accord sur les inclusions avec phar, mais en terme de performances tu y perds quoi qu'il arrive. A moins de bien gérer phar.cache_list

Dans tous les cas, on a beau tourner virer autour du pot, on en revient toujours à la même conclusion : à partir d'une certaine charge PHP est lent et il faut lui adjoindre des aides pour tenir des performances honorables.
Alors ça peut être de la minification, du cache d'opcode, de la compilation (à la volée ou pas) voire même un serveur d'applications... bref tout ce que vous voulez mais l'appareiller devient obligatoire.

**stealth35** · 19/01/2012, 17h59

Envoyé par Benjamin Delespierre

Stealth, je me suis toujours demandé d'où te venait cette aptitude à sortir de ton chapeau toutes les fonctions du manuel

Tu te les ai faites graver dans le cerveau ou quoi ?

je te donne mon secret :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print_r(get_defined_functions());

tu regardes tout des que tu connais pas la fonction tu regardes la doc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$functions = get_defined_functions();
foreach($functions['internal'] as $function) {
    printf('<a href="http://fr.php.net/manual/fr/function.%s.php">%s</a><br />', str_replace('_', '-', $function), $function);
}

**stealth35** · 19/01/2012, 18h02

Envoyé par rawsrc

Je suis bien d'accord sur les inclusions avec phar, mais en terme de performances tu y perds quoi qu'il arrive. A moins de bien gérer phar.cache_list

Dans tous les cas, on a beau tourner virer autour du pot, on en revient toujours à la même conclusion : à partir d'une certaine charge PHP est lent et il faut lui adjoindre des aides pour tenir des performances honorables.
Alors ça peut être de la minification, du cache d'opcode, de la compilation (à la volée ou pas) voire même un serveur d'applications... bref tout ce que vous voulez mais l'appareiller devient obligatoire.

je suis bien d'accord aussi, pour les appli Symfony2 (qui a quand même pas mal de fichier) le cache d'ocode d'APC est plus que nécessaire, j'ai un bon x2 en terme de chargement de fichier (et fois x3 avec la Mac Mini et son pauvre disque 5400tr)

Ensuite y'a des chose dynmaque certe mais qui au final sont statique, par exemple : un article de blog, ça sert a rien de faire un appelle a la base alors qui reste pareil, un cache HTTP sur la page est la bienvenue, donc PHP ne sera même pas appelé

j’attends le livre de Julien Pauli :
http://www.amazon.fr/Performances-PH.../dp/2212128002

**Benjamin Delespierre** · 19/01/2012, 18h11

Envoyé par stealth35

je te donne mon secret :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print_r(get_defined_functions());

tu regardes tout des que tu connais pas la fonction tu regardes la doc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$functions = get_defined_functions();
foreach($functions['internal'] as $function) {
    printf('<a href="http://fr.php.net/manual/fr/function.%s.php">%s</a><br />', str_replace('_', '-', $function), $function);
}

Tu viens de me donner une idée !

je suis bien d'accord aussi, pour les appli Symfony2 (qui a quand même pas mal de fichier) le cache d'ocode d'APC est plus que nécessaire, j'ai un bon x2 en terme de chargement de fichier (et fois x3 avec la Mac Mini et son pauvre disque 5400tr)

J'aimerai bien mais mon composant à vocation à rester indépendant de toute installation d'exts PECL vu qu'il est déployé principalement sur des hébergements mutualisés.
Et puis ça ne corrige pas vraiment le problème de fond: le chargement systématique des librairies.

Je suis en train de me documenter sur les méthodes de cache et de faire quelques benchmarks.
J'ai par exemple remarqué qu'un unserialize était moins long qu'un include de fichier PHP pour le même volume de données.