On Sat, Feb 19, 2005 at 12:40:01AM +0100, jeanluc wrote:
> Je pense que tes resultats montrent surtout le temps de chargement du
> programme (de l'interpreteur dans le cas python et perl), et non pas
> le temps de "traitement" de l'information utile.
> [...]
>
> Je dirais meme qu'il y a 3 durées :
> durée 1: lancement de l'interpreteur lui-meme
> durée 2: vitesse d'interpertation pour générer du code executable par le proc
> durée 3: rapidité du code généré
> [...]
C'est une très bonne remarque. Et Effectivement, je n'ai pas tenu compte
des conséquences des durées des étapes 1 et 2 sur le résultat global.
AMHA, le test, pour être pertinent devrait être réalisé sur des fichiers
plus conséquents pour marquer les différences entre chaque programme.
Toutefois, il ne faut pas non plus oublier qu'un programme avec tel
langage va être plus performant jusqu'à une certaine taille de fichier
et moins bon avec une taille bcp plus supérieure.
Pour tester l'exécution du programmme proprement dit (c'est-à-dire du
code à exécuter), il faut enlever à ses mesures les durées 1 et 2.
Mais ceci ssi on souhaite tester le code des programmes proprement dit.
Or ce n'était pas mon cas.
Ce n'était pas dans mon objectif de comparer le temps d'exécution du
code proprement dit et de dire machin rulez.
En fait, je m'en fou que perl est plus fort que
python ou vice-versa dans cette situation ; perl, ruby et python sont
des langages que j'apprécie pour leur qualité respective et selon telle
tache ou telle autre, j'utiliserai plutôt l'un que l'autre.
Ce que je voulais donner avec ces mesures, c'est le temps "global"
d'exécution d'une part des langages interprétés (comparons ce qui est
comparable) Perl, Python et Ruby (qui sont considérés d'être de la même
"famille") entre eux, et d'autre part des langages compilés C++ et Eiffel
entre eux. AMHA, lorsque l'on décide de choisir tel ou tel langage de
programmation interprété, il est important de tenir compte aussi de la
charge de l'interpréteur et donc, par extension, de la charge globale du
programme. A quoi sert un programme dont le temps d'exécution de code
est de 10ms si l'interpréteur met 10s à faire son travail alors qu'avec
un autre langage le code va prendre peut-être 20ms mais l'interpréteur
5s à faire son travail (les valeurs sont exagérées évidemment) ?
Ceci n'est plus vrai avec un serveur d'application : une fois lancée, il
n'est pas destiné à s'arrêter et donc ce qui est important est le code
exécuté proprement dit.
--
Miguel Moquillon <miguel.moquillon@???>
jabber://moqui@???
http://miguel.moquillon.free.fr
