Le ralentissement des performances des langages de programmation est-il vraiment une mauvaise chose? [fermé]

Voici comment je le vois.

Il y a du code machine et c'est tout ce dont les ordinateurs ont besoin pour exécuter quelque chose. Les ordinateurs ne se soucient pas des langages de programmation. Peu importe pour eux que le code machine provienne de Perl, Python ou PHP. Les langages de programmation ne servent pas les ordinateurs. Ils servent les programmeurs.

Certains langages de programmation fonctionnent plus lentement que d'autres, mais ce n'est pas nécessairement parce qu'il y a quelque chose qui ne va pas avec eux. Dans de nombreux cas, c'est parce qu'ils font plus de choses que les programmeurs auraient autrement à faire (c'est-à-dire la gestion de la mémoire) et en faisant ces choses, ils sont meilleurs dans ce qu'ils sont censés faire - servir les programmeurs.

Alors, les performances plus lentes des langages de programmation sont-elles vraiment une mauvaise chose?

Je ne pense pas que ce soit automatiquement mauvais. Python est plus lent que C ++, mais lorsque les deux sont assez rapides , Python peut être le meilleur choix pour le problème à résoudre, même s'il est plus lent .

C'est toujours un compromis. Pour les petites tâches ponctuelles, il est beaucoup plus rapide d'écrire un script Python qu'une application C ++ qui fait de même (l'exemple typique pour moi serait une sorte de traitement de texte par lots ou de parcourir une arborescence de répertoires et de faire quelque chose dans les fichiers), et je me fiche de savoir si cela prend 10 ms ou 1000 ms, même si c'est 100 fois plus lent, car cela peut me prendre la moitié du temps pour écrire et tester.

Bien sûr, ce serait bien si Python était aussi rapide que C ++, donc en ce sens, je suis d'accord avec votre affirmation que "slow = bad". Mais ensuite, j'ai plutôt un langage puissant qui s'exécute aussi vite que je le souhaite en ne faisant pas certaines choses (disons, les limites des tableaux vérifient les tableaux bruts) tant qu'il me permet de décider quand faire ce compromis (par exemple, en utilisant std: :vecteur).

Assez simple - être lent est une mauvaise chose

lorsque le programme nécessite un certain niveau de performance

car sans cette performance, vous ne remplissez pas les exigences.

Il peut s'agir d'une application métier qui doit traiter des requêtes dans un laps de temps acceptable jusqu'à un jeu qui doit afficher de nombreuses informations à l'écran à tout moment. Si le programme n'est pas assez rapide, il ne fonctionne tout simplement pas .

Regardez-le de cette façon: les ordinateurs sont stupides . Ils suivent péniblement les instructions que tout crétin avec une table trig pourrait suivre. Ils insistent obstinément pour faire ce que vous avez dit au lieu de ce que vous vouliez dire. Pas une once d'auto-direction ou d'intuition. C'est horrible.

La seule chose qu'un ordinateur a pour elle est, c'est rapide. Vraiment! Un knucklehead avec un classeur pourrait faire le même travail qu'une base de données. Un gars qui lance une presse à imprimer pourrait faire ce qu'Apache fait. Sérieusement! Et ils l'ont fait, pendant des centaines et des centaines d'années, en fait. Pourquoi un ordinateur est bon pour TOUT est sa vitesse.

Donc, un langage de programmation qui (par rapport à d'autres langages) ne parvient pas à exploiter qui manque le SEUL avantage d'utiliser des ordinateurs.

Un langage de programmation peut être de très haut niveau, "faire beaucoup", tout de même être très rapide. OCaml est un langage de niveau supérieur à PHP, mais il produit un code presque aussi rapide que C. Javascript est aussi dynamique que PHP, mais il peut être exécuté très rapidement. Donc, c'est principalement un problème avec une implémentation de langage, pas une conception. Les langages dynamiques sont plus difficiles à implémenter efficacement, mais pas impossible.

La vitesse peut être mesurée en termes d'exécution, de temps de développement initial et de maintenance (temps nécessaire pour résoudre les problèmes / bogues et produire un nouveau code et le déployer).

Les langages de script ont généralement un temps d'exécution plus lent mais un temps de maintenance plus rapide car vous pouvez souvent effectuer une modification et un déploiement rapides sans avoir à reconstruire un système entier, et parfois sans même avoir à arrêter et redémarrer.

Par conséquent, beaucoup dépend de la vitesse dont vous avez besoin.

Le contexte est également important. Charger votre configuration initiale en prenant 0,5 seconde au lieu de 0,1 seconde n'est pas un problème, mais au moment de l'exécution, prendre 0,5 seconde pour exécuter une requête au lieu de 0,1 seconde peut être un gros problème s'il doit gérer 100 requêtes, ce qui prend 50 secondes au lieu de dix.

Simple - les clients aiment les logiciels rapides. En fait, le but des ordinateurs est de calculer rapidement.

Lent est relatif. Si j'ai besoin de lire un port 10 fois par seconde, un langage qui ne peut pas créer un binaire qui peut le faire est trop lent. Si otoh j'écris une application Web où la séquence de demande / réponse entre le serveur et le navigateur / client est mesurée en secondes et l'utilisateur est susceptible de passer des minutes sur un écran avant de cliquer sur un bouton, un langage de programmation qui peut gérer le traitement des demandes en 1 seconde est probablement assez rapide (la plupart sont bien sûr beaucoup plus rapides).

Bien sûr, le langage de programmation peut être un facteur déterminant la vitesse d'exécution, mais ce ne sera pas le langage lui-même mais les compilateurs et / ou les runtimes qui l'accompagnent. Cela est évident vu le développement de Java, où les performances des machines virtuelles Java (même sur des environnements matériels identiques) ont considérablement augmenté au fil des ans. Et bien sûr, il est toujours possible d'écrire du code terriblement lent dans l'environnement de votre choix. De telles affirmations comme «C ++ est dix fois plus rapide que Java» sont automatiquement fausses à moins qu'elles ne soient qualifiées et quantifiées quant aux conditions exactes qui ont été testées et comment. Il est également possible de créer un test où Java est plus rapide que C ++, tout dépend de ce que vous utilisez comme code de test et de la façon dont vous l'exécutez.

Parce que les langages de programmation n'existent pas pour servir les programmeurs, ils existent pour créer des programmes pour servir les utilisateurs.

Si vous avez juste besoin d'un simple petit outil personnel pour faire quelque chose une fois, cela peut être aussi lent que vous le souhaitez. Mais une fois que vous commencez à déployer vers les utilisateurs, ils se soucient de la vitesse et de la mise à l'échelle, surtout s'ils vont l'utiliser à plusieurs reprises. (Par exemple, un programme d'installation peut être lent; le programme qu'il installe vaut mieux ne pas l'être.) Et ce n'est pas seulement la langue; c'est le programme dans son ensemble. Si votre programme est lent, les utilisateurs ne l'aimeront pas. Et si vous avez de la concurrence, les utilisateurs qui n'aiment pas votre programme sont une très mauvaise chose. Donc, un langage qui contribue à ce que les utilisateurs n'aiment pas votre programme (en le ralentissant) est mauvais.

Je fais partie d'une équipe qui écrit des logiciels de contrôle pour les médias audiovisuels. Il y a de fortes chances que votre station de radio ou de télévision préférée fonctionne dessus si vous êtes aux États-Unis. La performance est l'une des choses dont nous entendons le plus souvent parler les clients. Il a été initialement écrit pour de petites opérations à une seule station, mais maintenant nous signons des réseaux de diffusion et de câblodistribution majeurs avec des centaines de chaînes, et l'échelle commence à devenir un problème. Si nous ne pouvons pas faire avancer les choses rapidement pour eux, ils remettront leurs contrats de plusieurs millions de dollars à des gens qui le peuvent, et nous nous retrouverons sans emploi. C'est pourquoi nous utilisons un langage rapide et compilé et optimisons le diable de nos bases de données.

Parce que plus vite c'est mieux. Le temps, c'est de l'argent. Si vous écrivez un logiciel serveur et que vous utilisez un langage de programmation plus lent, vous achetez plus de serveurs. Si vous écrivez un logiciel sous film rétractable, vous perdez des clients face à des concurrents plus rapides.

Pour tout type de logiciel durable utilisé par les gens, nous le voulons généralement le plus rapidement possible. Au niveau de l'assemblage, le délai de mise sur le marché augmente trop et n'est pas rentable. Ce sont tous des compromis. D'un point de vue commercial, il pourrait être plus rentable de laisser les pauvres programmeurs déboguer les erreurs de mémoire en C ++, le faisant pendant plusieurs mois supplémentaires, si cela signifie que le produit est plus rapide que vos concurrents.

La vitesse est donc réellement importante dans de nombreux logiciels. Les langages lents sont considérés comme "mauvais" de nos jours parce qu'ils sont vraiment trop lents (Python peut facilement être 50x - 100x plus lent, et c'est trop)

Les langages de programmation existent pour servir les programmeurs.

Je ne sais pas comment vous en êtes arrivé à cette conclusion. Je dirais: les ingénieurs logiciels utilisent des langages de programmation pour leurs besoins.

Certains langages de programmation sont plus lents que d'autres, mais ce n'est pas parce qu'ils ont quelque chose de mal.

Ceci est également une déclaration floconneuse. Définissez ce que vous voulez dire en utilisant le mot «plus lent» ici. Plus lent pourrait signifier:

1. Les programmes finaux, qui réalisent la même chose, fonctionnent «plus lentement» dans une langue par rapport à une autre.
2. Le temps nécessaire pour créer le programme final peut être plus long (par conséquent, certains le qualifieraient de «plus lent»).

Ces deux problèmes qui me viennent à l'esprit sont également liés lorsqu'il y a une sorte de compromis entre le temps consacré au développement et aux performances.

Comme tout logiciel, être lent peut être le signe de problèmes sous-jacents / d'une mauvaise conception. Le design est certes un peu zeitgeist, mais cela n'enlève rien à ce fait, les principes de conception sur lesquels il est désormais basé sont obsolètes et considérés comme `` mauvais ''.

Prenez par exemple ASP classique et ASP.net.

Quelqu'un a déclaré que «les clients adorent les logiciels qui répondent aux exigences et au budget». Eh bien, c'est vrai - mais cela a tout à fait une incidence sur les logiciels lents, et cela, presque par définition, signifie des langages de programmation (et des cadres) et des algorithmes, et une configuration plus lents. Un langage de programmation lent est probablement la partie la plus importante de tout ce qui précède simplement parce que c'est une base à partir de laquelle vous aurez du mal à changer. Si vous utilisez une base de données Oracle et avez besoin de plus de performances, vous pouvez optimiser les tables / index / etc. Facile. Si vous avez un mauvais algorithme dans votre code, vous pouvez écrire un code différent. Si votre framework est lent, vous pouvez le remplacer - ce n'est pas si facile mais c'est faisable sans tout réécrire. Si votre langue est trop lente, vous devez pratiquement recommencer.

Voir Facebook pour les tracas dans lesquels ils se sont rendus pour faire fonctionner PHP assez rapidement quand ils avaient besoin d'évoluer.

Pour le reste d'entre nous, les «exigences de performances non fonctionnelles» sont souvent inscrites dans les spécifications, en particulier pour les applications Web évolutives. Si vous ne remplissez pas la "page, l'utilisateur doit l'afficher dans les 2 secondes suivant la demande" et vous perdez le contrat (ou payez des pénalités). (vous ne vous souciez peut-être pas du temps que les utilisateurs passent à regarder le sablier, mais le client le sait, c'est un coût énorme).

Par exemple, dans un grand centre d'appels, on m'a dit qu'ils avaient déterminé que pour chaque seconde que vous pouviez économiser sur le processus de prise d'appel, 1 appelant pouvait être «réduit». C'est de l'argent réel tout à coup, et une incitation énorme pour les patrons à obtenir des logiciels plus rapides, efficaces et plus utilisables.

Il y a beaucoup de temps à s'inquiéter du fait que les programmeurs produisent du code aussi rapidement que possible (puis testent et refactorisent en permanence, lol). J'ai trouvé que ce n'était pas autant un facteur que les gens le pensent - si vous êtes un expert dans votre langue, vous pouvez le coder beaucoup plus rapidement que si vous êtes inexpérimenté. Ainsi, un développeur C ++ expert peut écrire du code plus rapidement et plus précisément qu'un développeur PHP novice. Je pense donc que devenir un expert est plus important que de choisir une langue `` facile '' et c'est pourquoi je n'aime pas le culte de la `` réécriture dans le cool, de nouvelles choses '' qui semble être partout aujourd'hui.

Je soulignerai que la plupart des problèmes de performances existent parce que le programmeur a fait un mauvais travail, pas parce que le langage était trop lent. Vraiment, il y a beaucoup plus de choses pertinentes à se soucier de la performance que la langue que vous choisissez. Ce serait environ le numéro 1 203 407 e sur ma liste.

Alors, les performances plus lentes des langages de programmation sont-elles vraiment une mauvaise chose?

Toutes choses étant égales par ailleurs, aller plus vite est une bonne chose. Après tout, personne ne veut vraiment attendre plus longtemps pour certains résultats, et une fois ce résultat obtenu, il peut libérer des ressources pour d'autres choses.

Mais tout le reste n'est pas égal. Pour commencer, il est également important de produire le bon résultat, ou du moins suffisamment. (Si des résultats complètement incorrects sont autorisés, vous pouvez en effet les produire très rapidement et ils auront une valeur exactement nulle pour quiconque.) grand compromis. Les langues de niveau supérieur ont ici un avantage sur les langues de niveau inférieur, car leur ensemble plus riche de modèles facilite généralement l'expression d'un problème complexe sans trop de détails explicites.

Il est également généralement important de gérer le coût de production du logiciel en premier lieu, d'ajouter de nouvelles fonctionnalités comme vous le souhaitez et de le faire fonctionner au fur et à mesure que les systèmes sous-jacents changent. Les langages de niveau supérieur permettent généralement un délai de programmation plus rapide, et il est très utile de maintenir les coûts de programmation dans les limites du budget. En effet, le maintien des coûts à ce niveau permet de réaliser plus de choses différentes dans l'ensemble, ce qui est généralement une bonne chose.

Le dernier point clé à noter est qu'il n'est pas nécessaire d'utiliser un seul langage et que de nombreux systèmes logiciels ont une majorité de leurs composants qui ne sont pas critiques en termes de performances. L'utilisation d'un langage de bas niveau pour produire des composants hautes performances pour les bits critiques est judicieuse, tout en laissant les parties les moins critiques à un langage de haut niveau (afin de minimiser le coût de leur production) est éminemment sensé. De plus, les fonctionnalités qui font un bon langage de bas niveau (la capacité de contrôler précisément ce que fait la machine) ne sont pas les fonctionnalités qui font un bon langage de haut niveau (la capacité d'inférer les détails à partir de descriptions beaucoup plus petites): elles sont diamétralement opposés, donc pouvoir les coupler ensemble et les utiliser pour leurs forces et éviter leurs faiblesses, c'est vraiment une bonne chose.

Quels composants devraient recevoir le traitement haute performance? L'optimisation? Mesurez- les. Profilez- les. Trouvez la vérité plutôt que de deviner. Concentrez vos efforts là où cela fait le plus de bien.