C'est ce que je disais, l'utilisation de la bonne lib change �norm�ment la "rapidit�".
Cela d�pend du d�veloppeur qui doit bien utiliser Python, pour bien utiliser les libs. Une fois dans la lib (souvent faite en C, donc tout aussi rapide que... lui) la "vitesse" est la m�me. Les entr�s/sorties dans la lib, prennent du temps, il faut donc tenter de les limiter. C'est possible avec certaines libs, moins facile avec d'autres, et impossible pour certaines. Cela d�pend de l'architecture de la lib C et de la mani�re/qualit� donc elle a �t� "enrob�e" par le "wrapper" python. Il y a aussi certaines lib faites en python pur, et certaines d'entes-elles sont (si elles ont un certains succ�s), recod�e en C, et "architectur�e" pour limiter la surchage temporelle qu'impose le couche Python.
Oui, un type statique est plus rapide, mais le typage "dynamique" permet aussi de "coder autrement" une solution, utilisant une autre approche, qui fera que la vitesse sera au final sera plus rapide. Pour la d�tections des erreurs de typages "� la compilation", elle est plus safe qu'une d�tection dynamique au runtime, mais via les annotations, ont peut atteindre cette s�curit�, ou du moins s'en approcher.
L'interpr�tation du byte code prendra toujour "un temps" qui n'existe pas dans un langage qui compile directement le code source en code assembleur.
Il y'a aussi des cas ou la "vitesse" n'a pas trop de sens, genre attende d'une entr�e de l'utilisateur, mais qui est plus "simple" a coder en "Python", faisant l� gagner un temps de d�veloppement important, tout comme les types de base comme les listes, les dictionnaires, qui sont hyper simple a utiliser, faisant gagner l� aussi du temps.
Ensuite, il a y a aussi la "taille" du code, g�n�ralement plus petite en Python, donc de facto un d�veloppement plus "rapide". Enfin, la lisibilit� du code permet de "lire" un code Python et de le comprendre plus facilement, aidant aussi a d�velopper plus rapidement.
Tout cela est donc relatif, et c'est au cas par cas.
B�T et Peace & Love.
Partager