Zend FR

Je ne sais pas si vous utilisé Zend_Date, autant je suis vraiment emballé par l’API et le support i18n  mais je suis vraiment déçu par ses performances.

Après l’ajout de Zend_Date dans un script qui m’affiche un listing de 20 enregistrements je suis passé d’un temps d’exécution de 0.9s à 4s !!! Ce qui est énorme juste pour formater des dates !!!

En procédant à un petit test sur une boucle qui affiche 100 dates (pensez à une discussion dans un forum) j’obtiens un temps d’exécution de 5s (sur une distrib Debian propulsé par un PIII 350mhz).
Ce qui est d’autant plus étrange vu que je ne demande aucune donnée i18n sur le formatage.

require_once 'Zend/Date.php';
$zDate = new Zend_Date();
$zDate->setLocale( 'fr_FR' );
$format='dd/MM/YYYY';
$dateString = '2007-11-10 13:45:00';

$time_start = microtime(true);

for($i=0; $i<100; $i++){
    $zDate->set($dateString, 'YYYY-MM-dd HH:mm:ss');
    echo $zDate->get($format);
}

$time_end = microtime(true);
$time = $time_end - $time_start;
echo "Executed in: $time s\n";

Un profiling révèle que pour chaque composant de la date j’ai un accès au CLDR (fichier xml qui contient les infos pour l’internationalisation).

En activant les caches :
Zend_Locale::setCache($cache),     
Zend_Locale_Data::setCache($cache)

On arrive à un temps d’exécution de 2s, mais je trouve cela encore énorme. Pour comparaison la même boucle avec la nouvelle classe DateTime de php 5.2.0. et sup me donne un temps d’exécution de 0.022 s !!!

En conclusion je ne vais pas utiliser Zend_Date tout de suite mais DateTime. J’ai créer un class qui hérite de DateTime auquel j’ai ajouté des fonctionnalités.

A la vu du profiling je pense quand même qu’il y a pas mal de chose à faire pour amélioré les performances de Zend_Date, si vous être intéressé j’ai ouvert un ticket dans jira :
http://framework.zend.com/issues/browse/ZF-2311

Dernière modification par 2mx (19-12-2007 15:24:18)