Le Mercredi 16 Février 2005 22:43, Miguel Moquillon a écrit :
> Je vous laisse interpréter le résultat ... surtoût face à celui d'Eiffel :)
>
Biensur, j'ai eu ma propre interprétation dès que j'ai vu tes résultats.
Je n'avais prévu d'en parler, mais puisque tu nous y invite, voici.
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.
Donc, avec tes essais,
on ne peut pas dire que "perl" (ou Eiffel) optimise mieux le code que "python"
mais
l'interpreteur "python" est plus long à se lancer que l'interperteur "perl"
ou alors, à la limite
perl met moins long à interpreter(*) ce code que python.
(*)interpreter veut dire ici transformer en code executable, mais ne veut pas
exécuter le code produit par l'interprétation.
Pour s'en convaincre, il suffit de faire l'essai avec un fichier in.txt de taille nulle,
tu verras que les reslutats conduiront quasiment aux memes conclusions que celles
que tu présentes avec 150 lignes ou 400 lignes.
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é
En qui concerne la durée 3, je continue de penser que perl et python sont equivalents.
( à condition de programmer comme Mike, pas comme moi ;-) ..... ).
En ce qui concerne la durée 1 (et durée 2 ?), perl semble etre gagnant. Peut-etre que ce
sont "les batteries incluses" qui pèsent lourd ( la blague est pour Frédéric).
Biensur le C a des durées 1 et 2 nulles, et je pense qu'il est aussi gagnant sur durée 3.
Dans le cas de 150 lignes pour in.txt, durée 1 et 2 sont très loin d'etre negligeables
devant durée 3
Dans le cas de 3,3 millions de lignes pour in.txt, durée 3 est capitale. Et perl et python
semble à peu près equivalent.
Sinon, en pratique, 150 lignes peut etre un cas plus typique que 3,3 millions.
Donc, c'est vrai que si on a un serveur web qui fait beaucoup de tout petits traitements
(genre lire un petit fichier, extraire 2 ou 3 données et les mettre dans une DB) alors, ca vaut
le coup de se poser les bonnes questions pour choisir le bon language. Perl et python ne
seraient probablement pas adaptés .... mmhhh ... php serait-t-il vraiment un bon choix ?
j'y connais rien, mais pas si sur en fait. Après cet essai, ca fait réfléchir sur le temps de
lancement d'un interpreteur.
Un autre exemple. Je me suis donné un autre problème :
supposons que j'ai 5000 fichiers de 150 lignes à traiter.
python_v4.py est le dernier prog donné par Mike mais modifié pour prendre
autant de fichiers qu'on veut comme paramètre sur la ligne de commande.
J'ai fait l'essai avec deux méthodes :
1- bash# for i in *.txt; do python python_v4.py $i; done
ou bien
2- bash# python python_v4.py *.txt
Je suppose que vous avez devinez que l'essai 1 lance 5000 fois l'interpreteur et que
l'essai 2 ne le lance qu'une fois.
Dans les deux cas, les 5000 fichiers sont traités.
Il y a quasiment un rapport de vitesse 80 entre l'essai 1 et l'esai 2.
Donc, attention à l'interpretation "il est plus rapide que ..."
--
Jean-Luc
Pour info :
#bash> wc -l in.txt
150 in.txt
#bash> for i in $(seq 1 5000); do cp in.txt xxx${i}.in; done
#bash> ls -1 xxx*.in | wc -l
5000
#bash> time for i in xxx*.in; do python python_v4.py $i; done
real 2m4.297s
user 1m24.530s
sys 0m27.290s
#bash> time python python_v4.py xxx*.in
real 0m3.885s
user 0m2.050s
sys 0m1.160s
#bash> cat python_v4.py
#!/usr/bin/python
import sys
for file in sys.argv[1:]:
#print file
fileIn = open(file, "r")
fileOut = open(file + "_out.txt", "w")
for line in fileIn:
lineWrite=line[:-1]
try:
line = fileIn.next()
fileOut.write(lineWrite+line)
except :
fileOut.write(lineWrite + "\n")
fileIn.close()
fileOut.close()
