Tres bonne analyse a mon avis.
Cela fait un moment aussi que je pense que l'on melange un peu les
choux et les carottes ;-)
De plus, a savoir, Il est possible en python de directement utiliser le
.pyo qui est le code
deja (pre-)compile. le .pyc peut etre egalement utilise mais le .pyo est
a priori en plus
optimise.
on peux invoquer le .pyo avec
python -OO <monprgdefolie>.pyo
et pour le generer chacun sa technique pour ma part je lance
python -OO
et je fais import <monprgdefolie>
et le .pyo est genere.
A mon avis cela devrait recouper l'analyse.
Voila, mes deux cents.
"Python c'est plus que de la programmation c'est un etat d'esprit"
Non je dec...., il faut que je stoppe les cereales le matin ;-)
Francois.
jeanluc wrote:
>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 ..."
>
>
>
