Je fais du python à peu près tous les jours et je n'ai jamais jamais de problème de performance. J'ai fait des applis simples et certaines moyennement complexes. Jamais je n'ai encore rencontré les limites de performances de Python.
Python (et PyQt/PySide) est très bien (j'insiste) tant que l'application n'est pas trop grosse et ne fait pas trop de calcul. J'ai aussi fait beaucoup d'applications Python (du Web, des applications graphiques, du réseau), plutôt des petites (< 10000 lignes), le plus gros projet auquel j'ai participé étant Netzob.
Cependant, dès que tu fais du calcul tu te heurtes à la lenteur de Python. Par exemple dans Netzob, les parties calculatoires (alignement de séquence etc.) sont codés en C car Python est trop lent. Sur des tâches purement calculatoires, Python peut être 50 fois plus lent que du C. Un facteur 50, c'est sensible. Dans le domaine du Web, les frameworks Python sont plus lents que leurs équivalents JVM (Java, Scala, Clojure), C++ ou Go. Je rappelle aussi qu'il n'y a pas de multithread réel en Python à cause du Global Interpreter Lock (GIL) qui empêche deux threads de s'exécuter réellement en parallèle (donc impossibilité d'exploiter un processeur multicore, et multiprocessing n'est qu'une solution partielle à ce problème).
Évidemment s'il s'agit de faire un client FTP ou éditeur de texte en Python et de le faire tourner sur un Core i5, il n'y aura aucun problème de performance (et même des choses plus grosses).
Et il rame peu, pour preuve, il est en train de s'imposer comme langage de référence dans le calcul numérique scientifique.
Wow Wow... Doucement. Python est certes très utilisé dans le monde scientifique mais c'est bien souvent via des modules comme numpy ou scipy et qui sont écrits... en C pour des questions de performance !
D'autre part, il existe des dizaines projets à destination du monde scientifique ou non visant à accélérer l'exécution du code Python : numexpr, shedskin, pythran, pypy, ce qui montre bien qu'il y a un problème. Au passage Pypy arrive a être 5x plus rapide que CPython (l'implémentation de référence) sur des benchmarks calculatoires, preuve qu'il y a bien de la marge de manœuvre. ...
[^] # Re: Déprimant
Posté par X345 . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 5.
Python (et PyQt/PySide) est très bien (j'insiste) tant que l'application n'est pas trop grosse et ne fait pas trop de calcul. J'ai aussi fait beaucoup d'applications Python (du Web, des applications graphiques, du réseau), plutôt des petites (< 10000 lignes), le plus gros projet auquel j'ai participé étant Netzob.
Cependant, dès que tu fais du calcul tu te heurtes à la lenteur de Python. Par exemple dans Netzob, les parties calculatoires (alignement de séquence etc.) sont codés en C car Python est trop lent. Sur des tâches purement calculatoires, Python peut être 50 fois plus lent que du C. Un facteur 50, c'est sensible. Dans le domaine du Web, les frameworks Python sont plus lents que leurs équivalents JVM (Java, Scala, Clojure), C++ ou Go. Je rappelle aussi qu'il n'y a pas de multithread réel en Python à cause du Global Interpreter Lock (GIL) qui empêche deux threads de s'exécuter réellement en parallèle (donc impossibilité d'exploiter un processeur multicore, et multiprocessing n'est qu'une solution partielle à ce problème).
Évidemment s'il s'agit de faire un client FTP ou éditeur de texte en Python et de le faire tourner sur un Core i5, il n'y aura aucun problème de performance (et même des choses plus grosses).
Wow Wow... Doucement. Python est certes très utilisé dans le monde scientifique mais c'est bien souvent via des modules comme numpy ou scipy et qui sont écrits... en C pour des questions de performance !
D'autre part, il existe des dizaines projets à destination du monde scientifique ou non visant à accélérer l'exécution du code Python : numexpr, shedskin, pythran, pypy, ce qui montre bien qu'il y a un problème. Au passage Pypy arrive a être 5x plus rapide que CPython (l'implémentation de référence) sur des benchmarks calculatoires, preuve qu'il y a bien de la marge de manœuvre. ...
En résumé, non, c'est pas juste un mantra.