les performances de Python

Version imprimable

05/07/2019, 07h56
jiggyOne

les performances de Python

Hey,
J'apprends à programmer en python depuis peu avec le livre Apprendre Python 3 de Gérard Swimmen et je trouve que c'est un bon langage.
Mais je vois souvent ou même de la bouche de certaines personnes Python n'est pas performant et efficace par rapport aux autres langages (compilés,...) pour des applications ou logiciels à installer sur un bureau.
J'aimerais savoir si c'est fondé ou pas ?
Devrais je voir vers autre langage pour les applications pour bureau ?
05/07/2019, 08h25
tyrtamos

Bonjour,

Ceux qui disent que Python n'est pas performant sont surtout ceux qui ne connaissent pas bien le langage. De même que lorsqu'on dit que Python n'est qu'un langage de script alors qu'on peut faire avec des programmes complexes (graphiques, multimédias, gestion de base de données, réseau, etc...).

En fait si la partie purement interprétée est déjà assez performante, Python donne la main rapidement à des modules écrits en C ou C++ qui s'exécutent en langage machine. C'est le cas pour le calcul scientifique, les bibliothèques graphiques, etc... ainsi que les modules personnels qu'on a trouvé pertinent de traduire en C ou C++.

Une fois le programme Python au point, on peut le transformer en exécutable indépendant (avec pyinstaller, cx_freeze, ...) qui pourra être exécuté sur des PC qui n'ont pas Python installé (ou pas avec la bonne version). On peut même utiliser un "installeur" comme innosetup sous Windows, ou fabriquer un "paquet" sous Linux, et un utilisateur pourra installer le programme sur son PC sans savoir que c'est du Python!

Un petit exemple de programme Python multimédia avec la bibliothèque graphique PyQt5 qui permet de jouer des radios internet sur son PC: http://python.jpvweb.com/python/mesr...pyqt5_radioweb.

En ayant la facilité et la rapidité de développement de la partie interprétée, et la partie rapide des modules écrits en C ou C++, on a ainsi le "meilleur des deux mondes".

Bien sûr, des applications critiques de type temps réel nécessiteront probablement un autre langage plus adapté.
05/07/2019, 08h28
wiztricks

Salut,

Citation:

Envoyé par jiggyOne

J'aimerais savoir si c'est fondé ou pas ?

Sûr que c'est fondé: un langage interprété sera toujours plus lent qu'un langage compilé (moderne).

Mais dans la réalité, dès que vous allez programmer sérieusement vous allez utiliser Python pour "commander" des bibliothèques graphiques ou numériques écrites dans des langages comme C/C++ et qui seront, elles, compilées.

Côté performances, la différence sera négligeable pour autant que vous sachiez déléguer le gros du boulot à ces bibliothèques là. Sinon, rien ne vous empêche de compiler un sous ensemble de vos scripts Python grâce à des bibliothèques comme Cython.

Et s'il y a plein de solutions, cela ne doit pas vous faire négliger l'apprentissage d'autres langages que Python... mais attendez d'avoir un peu appris à programmer pour çà.

- W
05/07/2019, 08h55
jiggyOne

limites de python

quels sont les limites de python et des langages interprètes en général ?
05/07/2019, 10h04
wiztricks

Citation:

Envoyé par jiggyOne

quels sont les limites de python et des langages interprètes en général ?

Vous pourrez difficilement faire de la programmation système (mais certains langages compilés ne le peuvent pas non plus)... et la principale limite sera essentiellement (et pour un certain temps puisque vous débutez) dans vos compétences à faire avec.

- W
05/07/2019, 10h31
Bktero

Citation:

Envoyé par jiggyOne

Python n'est pas performant et efficace par rapport aux autres langages (compilés,...)

Il faut aussi voir ce qu'on attend d'un programme en terme de performances.

Si tu veux faire de l'acquisition vidéo en temps réel, traiter le flux vidéo pour faire de la détection faciale, et afficher la vidéo avec des carrés autour des têtes, il faut effectivement un programme qui ne perd pas de temps pour limiter au maximum le décalage entre la réalité et la vidéo affichées par ton programme.

Si tu veux faire une interface pour afficher les données météo de ta ville, tu t'en fiches sur le programme soit plus lent parce que tu utilises un langage interprété plutôt que compilé. Tu as la latence des requêtes sur un site web pour avoir les informations, les inconnues sur les performances sur le réseau. Alors si toutes les heures quand tu mets à jour ton affichage des données météo, ça met 10 secondes au lieu de 1, quelle différence ?
05/07/2019, 11h25
lg_53

J'appuie le propos de Bktero : Performant c'est un mot à relativiser. Selon 2 critères principaux : la taille des données que tu dois manipuler ET le temps de réponse maximale toléré (temps réel ou non, délai, etc ...)

La question est aussi passionnante que récurente.
Il est admis communément qu'un langage interprêté est plus lent qu'un langage compilé.
Mais dans la pratique, on constate souvent que l'interpréteur ne fait pas grand chose de plus lourd qu'un code généré par un compilateur. Il traduit le code, certes, mais c'est instantané.
Si l'on examine le byte code résultant, on constate qu'il s'agit surtout de manipulations de pile et de branchements dans le coeur du système.
Si l'on reste sur des instructions basiques, et que l'on programme sans utiliser la puissance du langage, d'accord, c'est plus lent, de beaucoup.
Par contre, si l'on utilise des instructions "puissantes", qui font beaucoup de travail en elle-même, alors la puissance du langage est fonction de son efficacité interne, qui est tout simplement celle d'un langage compilé.
Rappelons que python est programmé en C. Je postule que dans bien des cas, un code python est plus rapide qu'un code équivalent en C.
Essayez de faire une boucle en C qui fera la même chose qu'une liste en compréhension (une base de python), ce n'est pas certain que vous aurez un résultat plus rapide.
Jetez un coup d'oeil sur le code source de python, vous verrez que c'est extrêmement bien optimisé.

Je bavarde, mais pratiquons, ce sera plus parlant.

Le code suivant :
Code:

1 2 3 4 5 6 7 import dis def tst(): for x in range(100): if int(x/2) == x/2: print(x,end=' ') tst() dis.dis(tst)
dont voici le résultat :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 4 0 SETUP_LOOP 48 (to 50) 2 LOAD_GLOBAL 0 (range) 4 LOAD_CONST 1 (100) 6 CALL_FUNCTION 1 8 GET_ITER >> 10 FOR_ITER 36 (to 48) 12 STORE_FAST 0 (x) 5 14 LOAD_GLOBAL 1 (int) 16 LOAD_FAST 0 (x) 18 LOAD_CONST 2 (2) 20 BINARY_TRUE_DIVIDE 22 CALL_FUNCTION 1 24 LOAD_FAST 0 (x) 26 LOAD_CONST 2 (2) 28 BINARY_TRUE_DIVIDE 30 COMPARE_OP 2 (==) 32 POP_JUMP_IF_FALSE 10 6 34 LOAD_GLOBAL 2 (print) 36 LOAD_FAST 0 (x) 38 LOAD_CONST 3 (' ') 40 LOAD_CONST 4 (('end',)) 42 CALL_FUNCTION_KW 2 44 POP_TOP 46 JUMP_ABSOLUTE 10 >> 48 POP_BLOCK >> 50 LOAD_CONST 0 (None) 52 RETURN_VALUE
Le ligne 26 "46 JUMP_ABSOLUTE" nous laisse supposer un branchement, et donc un code assez lent, car une bonne partie de ces instructions vont être exécutées autant de fois que d'itérations dans la boucle. C'est normal, ce code python est à peine digne d'un débutant.

Par contre :
Code:

1 2 3 def tst(): print([x for x in range(100) if int(x/2) == x/2])
qui donne :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98] 11 0 LOAD_GLOBAL 0 (print) 2 LOAD_CONST 1 (<code object <listcomp> at 0x7f3762f7f8a0, file "lst.py", line 11>) 4 LOAD_CONST 2 ('tst2.<locals>.<listcomp>') 6 MAKE_FUNCTION 0 8 LOAD_GLOBAL 1 (range) 10 LOAD_CONST 3 (100) 12 CALL_FUNCTION 1 14 GET_ITER 16 CALL_FUNCTION 1 18 CALL_FUNCTION 1 20 POP_TOP 22 LOAD_CONST 0 (None) 24 RETURN_VALUE
et semble montrer l'absence de tout branchement.
J'en déduis que la liste en compréhension est gérée de façon optimum, en une fois, d'une façon qui serait peut-être difficile à faire aussi bien en C, car programmée une fois pour toute.

Je suis tenté de conclure que la puissance du langage fait loi, et non pas son caractère compilé/interprêté, qui me paraît une opposition obsolète depuis bien longtemps déjà. En fait, ce genre de discussion avait lieu à propos de java dans les années 90 ; ceci ne nous rajeunit pas...

Et sans donner dans le côté partisan, python est tellement fourni en modules ultra-puissants, que pour finir, je ne vois guère de langage aussi performant d'un point de vue global.

05/07/2019, 22h36
jmbain

Bof, après un test rapide, ce que je raconte n'est pas vérifié.
Je n'en reviens pas.
06/07/2019, 11h45
Sve@r

Bonjour

Citation:

Envoyé par jmbain

Je bavarde, mais pratiquons, ce sera plus parlant.

J'adore ce genre de fraicheur dans un discours :mrgreen:

Citation:

Envoyé par jmbain

print([x for x in range(100) if int(x/2) == x/2])

Je pense que si on veut faire un test de perfs, on partira quand-même d'un code plausible. A mon avis, aucun habitué de Python écrira if int(x/2) == x/2 quand il peut écrire if x//2 == x/2 ou même if x%2 == 0...

Citation:

Envoyé par jmbain

Bof, après un test rapide, ce que je raconte n'est pas vérifié.
Je n'en reviens pas.

Il n'y a rien de plus frustrant que d'avoir une théorie qui s'appuie sur un raisonnement correct et qui, donc, ne peut que se voir vérifiée... et qui ne l'est au final pas :mur:
Malheureusement je pense que ton test a dû être compromis par certaines optimisations internes. 8-)

Citation:

Envoyé par jiggyOne

J'aimerais savoir si c'est fondé ou pas ?

Je me souviens de mon premier projet en Python. Un truc pas vraiment difficile en soi mais qui effectuait énormément de calculs. J'ai donc abordé, en bon débutant de ce langage, le projet sous forme classique (des tableaux, des boucles, des calculs).
Au final, ça fonctionnait mais avec des données réelles (grosso-modo 60000 lignes de 8 colonnes) le bouzin mettait plus de 5mn pour donner un résultat.

Ensuite avec l'expérience j'y suis revenu. En tentant des solutions diverses encore et encore. A la fin, je suis passé par sqlite pour avoir la puissance du requêtage SQL (parce qu'il me fallait parfois éliminer certaines lignes selon le choix de l'utilisateur donc je pouvais, en SQL, mettre mes lignes en table puis ne récupérer que celles dont la colonne X était à True) et le truc est descendu à 30 secondes. Et je n'ai pas tenté numpy que je ne connais pas mais d'après les echo, peut-être que je pourrais gagner encore (mais bon, le projet est fini donc...)

Tout ça pour dire que oui, Python pur ok c'est lent. Mais Python + tout ce qui a été fait à côté et qu'on peut relier via un simple import sera quasiment aussi rapide qu'un compilé. Toutefois tout dépend au final de ce qu'on veut/peut mettre dans ce "quasiment"...
Perso j'aime bien cette page et surtout cette conclusion "Il y a des tas de raisons de ne pas choisir Python bien entendu, mais probablement la meilleure raison de le choisir, c’est qu’il y a peu de chance de se planter."

Citation:

Envoyé par jiggyOne

Devrais je voir vers autre langage pour les applications pour bureau ?

Avant de réfléchir à ce qui ne peut pas se faire en Python, je te conseillerais peut-être d'abord t'intéresser à ce qui a été fait en Python...
06/07/2019, 19h20
jiggyOne

merci c'était bien illustrer.Mais c'était quoi le projet ?
06/07/2019, 19h24
viper1094

Citation:

Envoyé par Sve@r

Citation:

Je bavarde, mais pratiquons, ce sera plus parlant.

J'adore ce genre de fraicheur dans un discours :mrgreen:

Hahaha elle est joli celle là.

Citation:

Envoyé par Sve@r

A mon avis, aucun habitué de Python écrira if int(x/2) == x/2 quand il peut écrire if x//2 == x/2 ou même if x%2 == 0...

Bien sur que non, aucun dev python ne fait de choses comme cela.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Python 3.6.8 (default, Jan 14 2019, 11:02:34) [GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
>>> import dis
>>> dis.dis("int(i/2) == i/2")
  1           0 LOAD_NAME                0 (int)
              2 LOAD_NAME                1 (i)
              4 LOAD_CONST               0 (2)
              6 BINARY_TRUE_DIVIDE
              8 CALL_FUNCTION            1
             10 LOAD_NAME                1 (i)
             12 LOAD_CONST               0 (2)
             14 BINARY_TRUE_DIVIDE
             16 COMPARE_OP               2 (==)
             18 RETURN_VALUE
>>> dis.dis("not i & 1")
  1           0 LOAD_NAME                0 (i)
              2 LOAD_CONST               0 (1)
              4 BINARY_AND
              6 UNARY_NOT
              8 RETURN_VALUE

CQFD

06/07/2019, 19h37
jiggyOne

aussi est-il important d'utiliser une machine virtuelle?
06/07/2019, 19h58
Sve@r

Sacré VinsS. J'avais pas pensé à "&" :mrgreen:
Ou peut-être que j'ai écrit un code que je voulais inconsciemment adaptable à tout diviseur ;)

Citation:

Envoyé par jiggyOne

merci c'était bien illustrer.Mais c'était quoi le projet ?

Analyse de signal

Citation:

Envoyé par jiggyOne

aussi est-il important d'utiliser une machine virtuelle?

Qu'entends-tu par "important" ? Ca dépend de ton besoin.
Moi par exemple je code sous Linux mais faut que mes trucs fonctionnent sous W7/W10 donc oui j'utilise des machines virtuelles pour tester avant de déployer.
Bref la virtualisation te permet de tester dans différents environnements mais ce n'est pas obligatoire pour simplement coder...

Citation:

Envoyé par jmbain

Rappelons que python est programmé en C. Je postule que dans bien des cas, un code python est plus rapide qu'un code équivalent en C.

Plus rapide ?! :mouarf: Faut pas déconner non plus. :mouarf:

Citation:

Envoyé par jmbain

Par contre :

Code:

1
2
3
 
def tst():
	print([x for x in range(100) if int(x/2) == x/2])

qui donne :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98]
 11           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (<code object <listcomp> at 0x7f3762f7f8a0, file "lst.py", line 11>)
              4 LOAD_CONST               2 ('tst2.<locals>.<listcomp>')
              6 MAKE_FUNCTION            0
              8 LOAD_GLOBAL              1 (range)
             10 LOAD_CONST               3 (100)
             12 CALL_FUNCTION            1
             14 GET_ITER
             16 CALL_FUNCTION            1
             18 CALL_FUNCTION            1
             20 POP_TOP
             22 LOAD_CONST               0 (None)
             24 RETURN_VALUE

et semble montrer l'absence de tout branchement.
J'en déduis que la liste en compréhension est gérée de façon optimum, en une fois, d'une façon qui serait peut-être difficile à faire aussi bien en C, car programmée une fois pour toute.

Citation:

Envoyé par jmbain

Bof, après un test rapide, ce que je raconte n'est pas vérifié.
Je n'en reviens pas.

Citation:

Envoyé par Sve@r

Il n'y a rien de plus frustrant que d'avoir une théorie qui s'appuie sur un raisonnement correct et qui, donc, ne peut que se voir vérifiée... et qui ne l'est au final pas :mur:

Je crois que vous n'avez pas compris ce bytecode.

Voici comment j'interprète ce bytecode :

La première instruction CALL_FUNCTION appelle range(100).

La deuxième instruction CALL_FUNCTION appelle une sous-fonction de la forme :

Code:

1
2
def the_subfunction(result_of_range_100):
   return [x for x in result_of_range_100 if int(x/2) == x/2]

sur le résultat de range(100). the_subfunction est la sous-fonction qui avait été construite et déposée dans la pile par les 3 instructions :

Code:

1
2
3
              2 LOAD_CONST               1 (<code object <listcomp> at 0x7f3762f7f8a0, file "lst.py", line 11>)
              4 LOAD_CONST               2 ('tst2.<locals>.<listcomp>')
              6 MAKE_FUNCTION            0

La troisième instruction CALL_FUNCTION appelle print sur le résultat précédent.

Des branchements, il y en a à deux endroits :

Il y en a plusieurs dans la fonction que j'ai appelé the_subfunction. Quand j'ai testé dis.dis(tst), j'ai eu deux code successifs : celui qui correspond à la fonction tst puis celui qui correspond à la sous-fonction que j'ai appelée the_subfunction :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
>>> dis.dis(tst)
  2           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (<code object <listcomp> at 0x000002B7132F4810, file "<stdin>", line 2>)
              4 LOAD_CONST               2 ('tst.<locals>.<listcomp>')
              6 MAKE_FUNCTION            0
              8 LOAD_GLOBAL              1 (range)
             10 LOAD_CONST               3 (100)
             12 CALL_FUNCTION            1
             14 GET_ITER
             16 CALL_FUNCTION            1
             18 CALL_FUNCTION            1
             20 POP_TOP
             22 LOAD_CONST               0 (None)
             24 RETURN_VALUE
 
Disassembly of <code object <listcomp> at 0x000002B7132F4810, file "<stdin>", line 2>:
  2           0 BUILD_LIST               0
              2 LOAD_FAST                0 (.0)
        >>    4 FOR_ITER                28 (to 34)
              6 STORE_FAST               1 (x)
              8 LOAD_GLOBAL              0 (int)
             10 LOAD_FAST                1 (x)
             12 LOAD_CONST               0 (2)
             14 BINARY_TRUE_DIVIDE
             16 CALL_FUNCTION            1
             18 LOAD_FAST                1 (x)
             20 LOAD_CONST               0 (2)
             22 BINARY_TRUE_DIVIDE
             24 COMPARE_OP               2 (==)
             26 POP_JUMP_IF_FALSE        4
             28 LOAD_FAST                1 (x)
             30 LIST_APPEND              2
             32 JUMP_ABSOLUTE            4
        >>   34 RETURN_VALUE
>>>

Dans ce bytecode, POP_JUMP_IF_FALSE correspond au saut du if int(x/2) == x/2. FOR_ITER gère le saut pour sortir de la boucle et JUMP_ABSOLUTE correspond au saut pour revenir au début de la boucle.

Il y a forcément des branchements dans l'appel de print sur la liste retournée par the_subfunction, car il y a forcément une boucle sur les éléments.

07/07/2019, 10h26
jiggyOne

Pour un blog, par exemple je voudrais utiliser un framework de Python soit Django soit Flask .Ou devrais opter pour du php pour me simplifier la tâche ?
07/07/2019, 12h10
wiztricks

Salut,

Citation:

Envoyé par jiggyOne

Ou devrais opter pour du php pour me simplifier la tâche ?

Si vous maîtrisez déjà PHP, sûr que réaliser un projet codé avec PHP sera plus simple: la réponse à cette question dépend de ce que vous connaissez et avec quels langages frameworks vous vous sentez le plus à l'aise.

Et si vous voulez réaliser un blog qui sorte un peu du lot (des blogs gratuits, c'est pas ce qui manque, vous pouvez même en créer sur developpez.com), il faudra maîtriser aussi HTML, CSS, JavaScript, protocoles réseaux, bases de données,...
qui sont des domaines qui sont difficile à aborder sans savoir un minimum programmer.

Si vous apprenez à programmer (accessoirement avec Python, car pour apprendre à programmer, il faut pratiquer et donc utiliser un langage de programmation) vos questions pourraient avoir du sens si devant les difficultés, la lenteur, les frustrations d'un apprentissage, vous vous demandiez s'il n'y a pas de solutions plus simple/rapide.

Plus simple et plus rapide serait de demander de faire le boulot à un programmeur... i.e. quelqu'un qui a eu la patience d'apprendre et la chance de réaliser quelques projets significatifs proches de celui que vous voulez.

Et si la seule chose qui vous intéresse est le résultat final, et qu'il sera plus à l'aise pour le coder en Java, C++ ou Ruby qu'est ce qui ferait souhaiter à ce que ce soit plutôt codé avec PHP ou avec Python?
Est-ce que çà va apporter des fonctionnalités supplémentaires à l'utilisateur final?
Est-ce que ce sera plus facile à maintenir parce que vous avez plus de compétences dans ces langages là?

Tout çà sont des questions "non techniques": çà n'apporte rien à l'utilisateur final mais se rapportent à un contexte spécifique à chaque projet et qui n'a rien à voir avec les langages de programmation retenus.

- W