Nouveau PHP, nouveau blog

Mon hébergeur ayant updaté PHP à la version 5.3 et Dotclear ne supportant (toujours pas) cette version de PHP, son code étant vieux comme le monde, j’ai décidé de me mettre à jour et ai donc installé un WordPress.

Pour l’instant, c’est from scratch et il n’y a rien mais je compte bien améliorer un peu tout ça à terme.

Vous pouvez retrouver tout vos articles préférés. Les URLs ont toutefois changés et je n’ai pas encore trouvé une bonne rewrite rule pour gérer ça proprement. Tant pis pour mon référencement !

Bonne suite donc…

RescueTime, calculez votre productivité !

Ne vous êtes vous jamais demandé combien de temps par jour vous passiez sur Facebook, à lire vos e-mails privés ou surfer sur des sites pas très professionnels ?

RescueTime est une petite application qui vous permet de répondre à cette question en enregistrant vos activités journalières sur votre poste de travail pour l’évaluer et dresser une statistique.

Continue reading

IE6 ou le temps qu’on perd, épisode 2 !

Microsoft s’y met également en poussant ses propres utilisateurs à mettre à jour son explorateur.

Une bonne nouvelle pour nous autres développeurs !

Et pour information, il suffit de se rendre ici pour mettre à jour son explorateur vers quelque chose de plus utilisable et supportable.

Il faut au minimum Windows XP avec le service pack 2.

Reste plus qu’à espérer que les grandes entreprises à l’infrastructure lourde leur emboiteront le pas car finalement, c’est ces réseaux qui évoluent le moins vite et surtout qui empêchent leurs utilisateurs de se mettre à jour.

Netbeans, mon nouvel IDE PHP

netbeans.gif

Voilà près de 5 ans que j’utilise tous les jours Eclipse avec le module phpeclipse pour réaliser mon travail. Je dois dire que au début, j’étais plutôt satisfait de Eclipse qui était, et d’assez loin, le meilleur éditeur PHP.

Eclipse a placé mes exigences en matière d’éditeur de code assez hautes. Comment se passer du saut sur la déclaration d’une fonction, de l’explorateur de fonctions, de l’aide contextuelle et des templates de code quand on y a goûté ?

Continue reading

Zend Framework – Optimisation des performances, exemple

Voici un petit exemple d’optimisation réalisé. J’ai analysé avec XDebug et WinCacheGrind l’appel à une page. Cette page affiche quelques centaines de lignes provenant d’une table d’une base de données.

Chacune des lignes est affichée avec un partial ce qui me permet d’utiliser le même affichage dans deux pages différentes. Les données de chaque ligne sont accédées via les getters et setters de Zend_Db_Table_Row et Zend_Db_Table_Rowset.

Voici tout d’abord l’analyse de la page sans aucune optimisation.

zend_opti_before.jpg

On constate un temps d’exécution de 488ms. En rouge, j’ai surligné les processus liés aux getters et en jaune ceux liés aux partials. On peut constaté d’ores et déjà qu’ils sont nombreux et au sommet des processus les plus consommateurs.

Voici, ensuite, le résultat après suppression des getters en utilisant des tableaux PHP standard à la place d’objet Zend.

zend_opti_after_getter.jpg

On est passé de 488ms d’exécution à 379ms. Un gain de l’ordre de 20%.

Ci-dessous, la même analyse après l’optimisation des partials et l’utilisation d’includes.

zend_opti_after_partial.jpg

Là, on gagne presque 30% de performance en passant à 225ms de temps d’exécution. Ce qui fait, au total, 50% de gain par rapport au code original.

Voici un petit code qui vous aidera à récupérer le chemin vers vos fichiers de script et donc utiliser un include à la place du helper partial :

 $moduleDir = Zend_Controller_Front::getInstance()                                   ->getControllerDirectory('default'); $viewsDir = dirname($moduleDir) . '/views/scripts'; <?include($viewsDir . '/controller/_partial.phtml')?> 

Bien entendu, on peut discuter de la manière de faire. Mais ce que j’essaie de démontrer est plutôt la lourdeur des tâches réalisées par Zend. Par exemple, on constate le chargement des plugins, le clonage des variables de la vue, le chargement des helpers, etc… à chaque utilisation de partial()

A utiliser, donc, avec parcimonie et toujours préférer les méthodes efficaces sur des codes récurrents.

Zend Framework – Optimisation des performances, quelques pistes

getter et setter

Les getter et setter dans PHP5 sont des outils très utiles. Malheureusement, à force de trop les utiliser, ils parviennent à rapidement plomber l’efficacité d’un code qui est pourtant simple.

Zend Framework, ici, n’échappe pas à la règle. Une solution simple pour éviter les contre-performances des classes comme Zend_Config ou Zend_Db_Table est de faire attention de ne pas abuser de la petite flèche vers la droite (->) et surtout pas dans des boucles.

On constate que rapidement, en bouclant sur un résultat de requête, par exemple, 20% du temps est pris simplement par les tests et la copie des données dans le getter.

La solution est évidemment d’utiliser des tableaux standards. La fonction toArray() règle le problème dans la plupart des cas.

partial

Le helper partial, quel bonheur ! On inclut un bout de code au milieu d’un autre bout de code et on peut le réutiliser partout. Oui, mais non…

Ce helper a la facheuse tendance de dupliquer la vue et énormément de code. Cette duplication a bien entendu un coût d’exécution. En le positionnant au milieu d’une boucle, la fuite de performance est inévitable.

Préférez encore l’utilisation du vieux include pour insérer votre code, quitte à déclarer les variables nécessaires avant son appel. Et ceci, surtout si vous vous trouvez dans un code récurrent.

Zend Date et Zend Locale

On en a déjà parlé dans un précédent billet. Zend_Date et Zend_Locale sont des gouffres à mémoire. Malheureusement, il s’avère que ce n’est pas leur unique problème.

A l’instanciation d’une classe utilisant Zend_Locale, une multitude de fichiers XML sont chargés en mémoire, prenant d’un seul coup quelques mégas. Ceux-ci contiennent les détails sur l’affichage des dates, heures et devises. Bien entendu, ceci a un coût au niveau du temps de chargement.

Il faut utiliser ces classes avec parcimonie. Surtout, éviter les instanciations multiples dans des boucles, comme toujours. Et si vraiment les performances sont trop mauvaises, n’hésitez pas à utiliser les bonnes vieilles fonctions PHP.

Conclusion

Zend Framework nous offre des outils mais leur philosophie n’a pas l’air d’être la performance. Malheureusement pour nous, il va falloir utiliser ces classes avec attention.

En optimisant un tout petit peu son code, on arrive à des gains de performances énormes, de l’ordre de 50 à 60% de temps d’exécution économisé. Donc ça en vaut largement la chandelle !

Vous pouvez facilement analyser les performances de votre code en suivant le petit tutoriel à disposition ici.

Suite à quelques expériences, j’ai de gros doute sur les performances de Zend_Application et également le générateur de CAPTCHA de Zend. Mais n’ayant pas pu faire de plus amples tests, j’évite de m’étendre là dessus pour l’instant.

Connaissez-vous d’autres gouffres à performance ? N’hésitez pas à en faire part… :)

Mise à jour: j’ai publié un exemple d’optimisation de Zend Framework en espérant que ça vous sera utile.

IE6, ou le temps qu’on perd…

C’est incroyable le temps qu’on perd à dégrader notre code pour le faire fonctionner sous IE6, encore utilisé par 15 à 25% d’internautes dont l’immobilisme va totalement à l’encontre des technologies qu’ils essaient d’utiliser.

Microsoft n’est fautif que d’avoir réussi à réunir autant d’incompatibilités et d’échecs dans un seul explorateur et de n’avoir jamais su corriger le tir. On parle ici du pauvre support des CSS avancés, des divers bugs et problèmes de sécurités, de l’impossibilité d’exécuter correctement un simple javascript ou encore d’avoir voulu réinventer les standards.

Le détenteur du dit browser, lui, est fautif de se contenter du pire et par la même occasion, de ralentir le progrès. Mais on constate rapidement que la plupart des machines qui supportent encore IE6 dans leur mémoire font parties de parcs informatiques professionnels (90%), bien souvent ceux de multinationales ou autres grandes entreprises.

Evidemment, les entreprises ne trouvent aucun intérêt à mettre à jour leur parc informatique pour un outils qui finalement, ne rapporte pas grand chose. Et surtout, ils n’en tireront aucun bénéfice. Les employés, eux, n’osent pas mettre à jour ou n’en ont simplement pas les droits.

Comme le dit si bien Mark Trammell: “demander aux utilisateurs de mettre à jour leur explorateur est non seulement inutile mais surtout sadique”.

Pour les développeurs web, bien entendu, c’est l’enfer du devoir. Il est hors de question de refuser le portage sur IE6 sur des sites marchands, car on perdrait un quart de clientèle. Comment ainsi dire qu’on se soucie d’augmenter l’impact du site réalisé ?

En fait, la question n’est pas vraiment de ne plus supporter IE6, ce n’est pas possible. Mais la vraie question est de savoir quand est-ce que IE6 va disparaître suffisamment pour qu’une agence web puisse justifier le fait d’arrêter de s’en soucier ?

Car mine de rien, si les entreprises qui persistent à obliger l’utilisation de cet explorateur faisait un rapide calcul du temps perdu (80% du temps passé sur le développement du CSS et Javascript est investi dans les soucis de compatibilité avec IE6) auprès de leur agence web, ça fait bien longtemps que le pas aurait été franchis.

Et d’ici là, nous continuerons à perdre notre temps et à doubler nos factures pour supporter les technologies dépassées.