Donc pour cette occasion un peu spéciale, je vais vous présenter une méthode un peu inattendue pour calculer Pi. On va utiliser la fonction rand().

On va utiliser le hasard et les probabilités. Fuyez pas, vous allez voir, c’est sympa. C’est la méthode de Monte-Carlo (vous savez, ses casinos, ses jeux de hasard…).

Regardons cette figure présentant un quart de disque de rayon 1 :

L’aire de ce quart de disque est de Pi / 4 et l’aire totale du carré est de 1.

Le principe est simple : on va tirer des points au hasard. La probabilité (notons la P) que chaque point soit dans ce quart de cercle est donc de P=Pi/4. Et cette probabilité, on va la calculer en faisant un tirage de N points. Il y en aura disons X qui tomberont dans le quart de cercle. On divise X par N et on a notre probabilité P.

Finalement, on a P=Pi/4 et P=X/N donc Pi/4=X/N d’où Pi=4*X/N.

On tire alors un point au hasard. On va utiliser la fonction rand (ou mt_rand, plus rapide et meilleure au niveau distribution aléatoire) pour déterminer ses coordonnées X et Y. Et s’il vérifie X²+Y² < 1 alors il est dans le quart de cercle. On répète ça un paquet de fois et le tour est joué.

Voyons comment on code ça en PHP. J’ai optimisé un peu la chose en ne ramenant pas les coordonnées dans [0,1]² ce qui évite des divisions. Le code :

<?php
$totalDotNumber = 100001;

$inCircleDotNumber = 0;
$maxRand = mt_getrandmax();
$maxRand_pow2 = pow($maxRand, 2);

for ($i=0; $i<$totalDotNumber; $i++) {
    if ( (pow(mt_rand(), 2)+pow(mt_rand(), 2) ) < $maxRand_pow2) {
        $inCircleDotNumber++;
    }
}

$frequency = $inCircleDotNumber / $totalDotNumber;
$pi = $frequency*4;

echo 'Points tirés : '.$totalDotNumber."\n";
echo 'dont dans le cercle : '.$inCircleDotNumber."\n";
echo 'Fréquence : '.$frequency.' (=Pi/4)'."\n";
echo 'd\'où : Pi = '.$pi."\n";
?>

On tire 500 000 points, ça prend 5 secondes et on obtient par exemple Pi=3,14436971126. Bon la précision n’est pas fameuse, mais on a bien (heu souvent…) 3,14 et des poussières.

On va s’arrêter là avec Pi, on va pas chercher à améliorer la chose, c’était juste pour le principe. La méthode de Monte-Carlo permet de calculer des intégrales de dimensions supérieure à 1 (avec 2 on a des aires, 3 des volumes, 4 c’est pour Albert Einstein dont c’est l’anniversaire aujourd’hui…).

Moi, ça m’épate. Pas vous ?

Les développeurs de Facebook ont mis au point HipHop for PHP. Pas si loin du compilateur PHP tel que Roadsand ou phc, HipHop réalise une traduction du code source PHP en C++ et se charge de le compiler en embarquant un serveur HTTP léger.

Alors on entend tout et rien à son sujet, alors mettons quelques éléments de compréhension sur la table.

Optimiser son application / son site est un domaine en soi. On peut mettre en cache les résultats des appels aux bases de données (via la base elle-même ou un autre moyen), mettre en cache des parties ou des pages entières générées… Memcached sera votre ami dans bien des cas. Je ne parle même pas d’une utilisation optimale de plusieurs serveurs HTTP (un pour les données statiques, un autre pour les scripts).

Enfin bref, on arrive vite à une limite, un appel où tout est en cache. Et quand on veut améliorer les performances, il faut se tourner du côté de PHP.

Il est déjà important de savoir comment fonctionne PHP. Quand on appelle un script, il est parsé, puis traduit en opcode lequel opcode est ensuite lancé dans une machine virtuelle qui fera le reste du boulot (traduction en instructions CPU et exécution). Ceci à chaque fois.

On peut évidemment optimiser un peu ça. Il y a principalement les caches d’opcode (APC, eAccelerator…). Mais on arrive vite à une autre limite, la machine virtuelle prendra bien un opcode caché, mais elle refera éternellement le même boulot.

L’idée est alors de compiler le PHP. Passons sur phc qui semble inactif.

On a d’un côté Roadsand, qui proposent une autre implémentation de PHP et qui vont effectivement traduire votre script en instructions binaires pour le CPU (bref compiler). Et de l’autre on a HipHop qui va traduire votre script PHP en C++, puis le compiler. Pourquoi j’ai séparé les deux ? Ils arrivent au même résultat. Mais par des moyens différents. On a un binaire. Selon les possibilités, il intègre son serveur HTTP, ou bien il dialogue via FastCGI avec un serveur HTTP.

Roadsend permet du runtime eval (eval, include), HipHop non et le sacrifie fièrement. On va pas rentrer dans les détails inutiles ici.

Je passe aussi l’optimisation au sens propre du code : profilage, blablabla et tout et tout. Ça se fait très bien et permet de voir des défauts d’architecture.

Bref, voyons ce qui nous a amené ici : l’optimisation, compiler PHP et les diverses conneries entendues. Ne retenons qu’une seule chose entendue, qui n’est pas foncièrement une connerie et qui mérite nuance et explication. Les conneries, elles, elles resteront.

Lu chez Maxime Valette :

Avant d’en arriver au stade d’avoir besoin de compiler du PHP transformé en C++, il faudrait déjà penser à s’affranchir de son framework qui ne peut que ralentir l’exécution de son site.

Bon, un framework, pourquoi ? Si Yahoo a choisi Symfony, c’est pour une bonne raison : le développement. Ils savaient très bien que c’est une surcharge de PHP. Mais un développement en équipe, agile, reposant sur des briques découplables, testable est plus qu’un confort. C’est générique. mais c’est un gain d’argent. Un développeur coûte cher. Les serveurs, c’est pas cher. Seule la bande passante est chère. (comparativement)

Il y a des cas où le service est relativement simple, avec une évolution limitée des fonctionnalités. Dans ce cas, oui, faites sans framework. Il ne sert à rien de sortir le marteau pilon pour écraser la mouche. Vous pouvez, mais ne râlez pas à propos de performance sur la lourdeur du framework. Vous avez fait un choix, celui de penser aux capacités de développement avant tout. Si vous voulez, vous pouvez créer votre propre framework, adapté à votre utilisation, pour combiner le meilleur des deux. Mais quand vous aurez tout optimisé, système de cache et tout et tout, alors PHP sera votre facteur limitant, du fait de votre framework. The bottleneck.

Bon, c’est assez tranché, mais tout ça pour vous dire que le PHP peut devenir le facteur limitant. Parce que déjà, si quelque chose est en cache, il faut bien à un moment ou à un autre l’y mettre. Et puis quand tout sort de cache, il y a quand même du code qui s’exécute.

Pas convaincu ? Essayez de générer un fichier PDF à l’aide de FPDF. Pas le truc de Mickey, un gros PDF, pleins de pages. Par exemple, 5000 bons de commandes en un seul PDF. Vous allez le sentir le bottleneck, vous allez sentir du PHP pur qui tourne. Récupérer les infos de la base de donnée c’est du gâteau à côté (c’est peut-être même déjà en cache ?). Les appels d’appels de re-appels de fonctions, de méthodes, d’objets… c’est élégant, mais ça a un coût.

Donc, compiler PHP peut-être une porte à ouvrir, si on veut gagner en terme de performance. Facebook en était là. Et c’est tant mieux, ça complète la voie.

Crédit photo : DragonBe.

Cela venait d’un caractère UTF8 appelé le BOM (Byte Order Mark – U+FEFF) qui est censé donné l’ordre de lecture des données. Sauf qu’en UTF8, il n’y a qu’un sens, donc ce BOM ne sert à rien. Du coup, je sais même pas pourquoi il existe. Ils se trouvent au tout début de fichier.

Si ce n’était que cela, ça irait. Mais voilà, PHP les envoie et les navigateurs les affichent ces cons de BOM. Cela pose donc deux problèmes : un possible envoi de header prématuré avec PHP (génant) et ce fameux espace à la noix dont on a mis 2h à trouver d’où il sortait.

Les symptômes :

• Erreur PHP « headers already sent » alors que vous avez apparemment rien envoyé au navigateur ;
• Vous avez l’encodage UTF8 de détecté : l’espace blanc à la c..n (si votre fond est blanc, sinon ça peut être un espace bleu…);
• Vous forcez l’encodage du navigateur en ISO-8859-1 :  apparait à la place de l’espace blanc ;

Pour résoudre ça, si vous avez l’option (idiote soit dit en passant) de pouvoir enregistrer en UTF8 avec ou sans BOM dans votre éditeur favori, vous choisirez la version sans BOM.

Sinon, vous sortez votre éditeur héxadécimal et la séquence à éradiquer est EFBBBF. En général il se trouve au tout début du fichier. Mais attention, ce caractère de 3 octets est vil et mesquin, avec des copiés-collés, il peut se multiplier et se retrouver pas qu’au début. (Sous VIM il apparait en tant que <FEFF> mais uniquement s’il n’est pas au début, s’il l’est, on le voit pas).

Il aura fallu que je rapatrie des fichiers PHP UTF8 de Windows pour voir arriver ce genre de merdouille. Robix, Linux, c’est pour quand ?

Quand on accède à des variables non déclarées, cela a un coût en terme de performance. En effet, PHP tente de la trouver, constate qu’il n’y arrive pas et lève une erreur de type E_WARNING, et ce même si vous ne les affichez pas. Démonstration.

Exécutons 100 000 fois le code de référence, la variable $variable n’étant pas déclarée :

if ($variable=='test')
  { }

Cela prend en moyenne 180ms.

Voyons le code, amélioré :

if (isset($variable) && $variable=='test')
  { }

100 000 exécutions prennent alors en moyenne 42ms, soit une amélioration de 75% en terme de rapidité d’exécution.

Ce test donne les même résultats que ce soit une variable ($test), un élément de tableau ($test['test']) ou autre.

PHP est souple au niveau des variables (déclaration, typage), l’avantage en terme de programmation a un coût en terme de performances.

Si vous voulez améliorer celles de votre app, laissez s’afficher les erreurs E_WARNING : en effet ce n’est pas parce qu’elles ne sont pas affichées par votre configuration de PHP qu’elles ne sont pas présentes. PHP lèvent ces erreurs quoiqu’il arrive, donc mieux vaut les voir et les éradiquer.

Déclarez explicitement vos variables, ou testez en premier leur existance via isset() avant d’y accéder.

Crédit photo : DragonBe.