Et quand “on” a une boucle avec très peu d’instructions dedans, il y a des gens – dont je ne suis pas – qui sont très contents de gagner 10% par ci par là….. ce qui semble réalisable en passant d’une boucle avec while à une boucle dans un intervalle…

Les gains à espèrer viendraient donc d’un appel “à” une dll/so ,( en simplifiant plus qu’hâtivement); ceci est un reflexe que j’espère naturel chez les riens, (chez les perliens, pythoniens , je n’en sais ….rien) : dés que ça devient lent, au point d’être gênant, ils réecrivent les bouts de code (une fois identifiés comme lents…. ce n’est pas un mince problème, sans profileur ou …. sans bon sens) en C, C++, Fortran {dans ce cas -manipulation sur des caractères- et ce contexte (solutions déjà en C et C++ ce serait une erreur), suivant leurs goûts, leurs talents ou la nature du problème….
avec un gain d’un facteur 50…. (je laisse un peu de marge pour l’appel de fonction).
Ceci nécessite de gérer 2 codes dans des sources distincts.

J’ai également fait l’essai en remplaçant « while l>0: » par « for i in range(1L,1000000L): ».

Le temps d’exécution du code de gestion de la boucle cumulé avec celui de 1000000 décrémentations est respectivement de 0,30 secondes pour la version avec le « while » et de 0,25 secondes avec le « for ».

Dans les deux cas, c’est tout à fait marginal.

Pour retablir le sentiment d’avoir été traité avec équité chez tous les utilisateurs de langage interpreté (en tous cas, ceux qui ont besoin d’évaluation des temps) je propose de rajouter une seconde boucle presque vide de meme longueur.
De toutes façon, ça peut être interessant de connaître ce temps et ne remet pas en cause la façon de mesurer le temps d’execution d’un algorithme ….

startvide = time.time()

# début mesure du temps d’exécution d’une boucle vide

nombre = 1000000L # l peut être confondu avec 1 -un-
while nombre >0:
nombre-=1 #la boucle vide, qui peut pénaliser

finbouclevide = time.time()