Pourquoi les gens disent-ils toujours Java est lent?
Pendant longtemps, dans SO et ailleurs Java a la réputation d'être lent. De blagues à nombreux commentaires dans les questions et réponses, les gens croient toujours que Java est lent, basé uniquement sur son expérience dans les années 90.
C'est mon problème: nous avons réfuté (la plupart) des raisons pour lesquelles les gens croient que Java est lent. En dehors de petites choses, Java est assez rapide.
Alors pourquoi est-ce que les gens refusent toujours de croire que Java est rapide maintenant? Cela fait-il partie de leur état d'esprit que tout ce qui n'est pas C/C++ est lent? Est-ce parce que les gens ne vérifient pas au fil du temps? Est-ce parce que les gens sont simplement biaisés?
Ce sont les applications. Comme vous le constatez, nous avons prouvé, maintes et maintes fois, que dans des scénarios artificiels Java peut rencontrer ou même battre les performances de des langages dits "performants" comme le C, C++, LISP, VB6 ou JavaScript. Et lorsqu'ils sont présentés avec de telles preuves, la plupart des opposants sains d'esprit ouvriront la tête de honte et promettent de ne plus jamais répandre une telle calomnie.
... mais ensuite, ils lancent Eclipse, ou NetBeans, ou Guiffy, ou activent la prise en charge Java dans leur navigateur, ou essaient d'exécuter une application sur leur téléphone préféré. Et ils attendent pour qu'il devienne réactif ...
...et attendre...
...et attendre...
...et attendre...
...et attendre...
...et...
... qu'est-ce que j'ai promis de ne plus jamais faire? Désolé, doit s'être assoupi ...
Cette question fonctionne sur de fausses prémisses: là où ça compte, Java est encore lent. Là où ça compte, ce sont des algorithmes lourds en calcul sur de grands ensembles de données. Certes, ces peuvent être optimisés, parfois pour être à égalité avec le code C/C++, mais seulement au prix de la modularité et de la généricité. Le code C++ efficace peut être conçu pour être générique et utilisable comme bibliothèque à usage général. Java ne peut pas. Regardez simplement le Array.sort méthode, qui utilise différentes implémentations pour tous les types fondamentaux, et dont la variante d'objet est toujours beaucoup plus lente que le générique C++ sort car ces objets doivent distribuer dynamiquement les comparaisons d'égalité.
Certes, les optimisations juste à temps effectuées par le moteur HotSpot peuvent en fait prédire la cible de ces appels virtuels et tenter de les aligner. Mais c'est toujours plus lent que l'appel directement en ligne qui est distribué dans la méthode C++ ’sort.
Un ancien collègue a fait des comparaisons comparatives d'un problème sur d'énormes ensembles de données ( q - comptage de grammes en utilisant des formes dynamiques) avec une implémentation C++ et un modèle orienté objet Java implémentation. Le code Java était plus lent que le code C++).
Bien sûr, cela compare des pommes avec des oranges. Mais le fait est que l'implémentation Java était la meilleure implémentation possible (en termes de performances, étant donné le degré de modularité requis pour une bibliothèque), tout comme l'implémentation C++.
Malheureusement, les données de référence ne sont pas disponibles gratuitement, mais d'autres ont trouvé des chiffres similaires en comparant les frais généraux d'abstraction à l'exécution. Par exemple, Scott Meyers écrit dans STL efficace sur la surcharge de la fonction générique qsort de C:
Le tri de C++ embarrasse pratiquement toujours le qsort de C en matière de vitesse. […] Au moment de l'exécution, sort fait des appels en ligne à sa fonction de comparaison… tandis que qsort appelle sa fonction de comparaison via un pointeur. […] Dans mes tests sur un vecteur d'un million de doubles, [trier] a fonctionné jusqu'à 670% plus vite…
Parce que c'est lent ... dans certaines applications. Les applications de bureau doivent être réactives dès le début et la surcharge de démarrage compte comme lente.
D'un autre côté, si vous exécutez un serveur, peu importe s'il y a du chauffage (analyse et compilation JIT) - vous le faites une fois dans la lune bleue, donc la plupart du temps cela ne peut pas être considéré comme complètement lent.
Je dirais que c'est parce que lorsque les gens l'ont rencontré pour la première fois, c'était lent. Sur cette base, ils en ont fait une impression. Cette impression ne changera probablement pas s'ils ne l'utilisent pas, et ils ne l'utilisent pas à cause de cette impression - c'est un cercle vicieux.
Je dois admettre que j'avais l'impression que Java était lent, et oui, c'était de mon exposition précédente. J'ai maintenant changé de langue et j'ai eu une exposition extrêmement limitée à Java depuis lors. Par conséquent, mon opinion n'a pas beaucoup changé.
Parce qu'il faut une génération pour changer les perceptions des gens sur un produit
Cela n'a rien à voir avec la vitesse à laquelle Java devient. Dans l'esprit des gens Java est un identificateur de const associé au mot 'slow'. Il n'y a pas grand-chose, rien ou Oracle peut y remédier.
Soyez simplement heureux qu'Oracle n'ait pas détruit la culture de programmation Java (encore)) en faisant quoi que ce soit téméraire ou stupide . Comme facturer des coûts de licence excessifs pour l'utiliser. Ou poursuivre en justice personnes basées sur des brevets logiciels appartenant à Sun. :: soupir ::
Je déteste être le naysayer ici, mais, à moins qu'Oracle et Google ne règlent le Java lutte à des conditions agréables, ou que Google soit obligé d'acheter Java et en fait un plate-forme open source "appropriée", Java est en passe d'être l'enfant sur le terrain de jeu qui a des poux. IE, personne ne voudra le toucher avec un poteau de 20 pieds.
Note: Juste pour être clair, quand je dis génération, je parle en termes humains et non informatiques. IE, jusqu'à ce que les personnes qui détiennent cette perception meurent de vieillesse ou soient remplacées par une génération plus jeune, la perception restera vraie. Pensez en termes de 5 décennies et non de 5 ans.
Une des raisons est que les gens font confiance à ce que les autres disent au lieu de ce qu'ils voient.
D'après ce qu'on m'a dit quand j'ai commencé la programmation, Java est "plus lent" que C++, et pourquoi Java pourrait être utilisé parce qu'il est "pratique et plus facile ". On pense généralement que Java apporte sécurité et commodité, au détriment des performances. Même lorsque plus tard C # est inventé, les gens pensent qu'il est plus rapide que Java parce que c'est "natif".
Mais la vérité que les gens voient sans le ressentir, c'est que, Eclipse, le IDE qui est construit avec Java, est absolument le PLUS RAPIDE IDE en classe. J'ai utilisé presque tous les IDE de flux principal, ceux de MS et GNU, Borland ..., Eclipse est le roi absolu des IDE, en grande partie à cause de sa rapidité.
Une autre raison est son temps de démarrage long.
Java n'est pas adapté au développement d'une petite application qui reste dans la barre d'état système, consomme un peu de mémoire, affiche une boîte de dialogue vous rappelant de faire une pause; ou un bloc-notes que vous utilisez pour ouvrir un fichier texte, le lire et le fermer. Il devrait être utilisé sur quelque chose de GRAND, comme un serveur Web qui est toujours là, faire une utilisation optimisée de vos ressources informatiques, répondre à des millions de demandes toutes les heures. Ou une IDE comme Eclipse qui gère des milliers de fichiers d'espace de travail. Vous ne savez pas que vous Java est rapide jusqu'à ce qu'elle ait fonctionné pendant au moins plusieurs heures, Je crois.
@bigown "Pourquoi les gens disent-ils toujours Java est lent?"
Parce qu'ils sont stupides. Parce qu'ils n'ont aucune expérience de travail, mais pensent qu'ils sont l'incarnation vivante de Dikjstra ou la seconde venue de Linus Torvald, oh je ne sais pas. Les raisons de dire une chose aussi retardée sont si nombreuses, mais généralement la stupidité, le fanboyisme subjectif et la prostitution émotionnelle semblent être derrière eux.
Disons cela pour que vous puissiez voir la vérité de ce que je viens de dire ci-dessus:
Premièrement, ce qui est lent, dans quel contexte, pour quoi, dans quelles conditions, avec quel objectif d'ingénierie/scientifique/commercial (pour dire ça te fait chier n'en fait pas partie.) Toute personne qui dit " X est lent "pour toute technologie X, ou simplement" X est Y "où Y est un certain type de déclaration négative, sans répondre à aucune des questions ci-dessus devrait être rejeté comme un idiot. De telles déclarations n'ont pas leur place dans l'ingénierie. En politique et dans les salons de discussion pour mineurs peut-être, mais pas en ingénierie.
Deuxièmement, la plupart de ces imbéciles égarés pleurent à propos de Java étant lent parce que ZOMG, leur Eclipse prend une éternité à se déclencher (gee, charge la chose avec tous les plug-ins et devine ce qui se passe.) de ces imbéciles ne savent même pas comment régler le jvm pour qu'Eclipse fonctionne rapidement (ou pour toute Java d'ailleurs). Autrement dit, ils n'ont aucune idée de l'optimisation des performances, ce qui est une réalité non seulement pour Java, mais pour tout système non trivial, que ce soit du matériel ou des logiciels. Donc là, ils se désarment pour toute validité technique en faisant de telles déclarations stupides.
Troisièmement, considérons à quoi sert l'essentiel du développement Java Java: back end OLTP d'abord et avant tout; les systèmes de surveillance venant en deuxième position. Les deux types de systèmes sont destinés à: fonctionner en grappes, et pour fonctionner sans interruption pendant des semaines, voire des mois. Est-il vraiment important que votre petite application Eclipse ou jouet prenne une minute ou deux à se charger lorsque le but de REAL Java apps est courir pendant des périodes prolongées? Contexte, personnes, contexte.
Enfin, l'épine dorsale de OLTP sur Google et Ebay fonctionne sur Java. Je prendrais cela comme une preuve par contradiction que Java n'est pas lent (du moins pour des conditions qui importent, pas pour de petites expériences de jouets, des repères et des preuves annecdotiques invérifiables faites spécifiquement dans le but de dire "le X est lent, c'est nul".
Il y a l'ingénierie et le fanboyisme. Devinez à quelle catégorie des déclarations comme celles-ci appartiennent?
Parce que c'est le cas, pouvons-nous clore ce sujet une fois pour toutes?
https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [faites défiler les tableaux, Java est 3.7 -12,6 fois plus lent que C++, selon les recherches des employés de Google]
P.S .: Si ce n'est pas le cas, nommez-moi au moins un snappy Java app pour commencer, je n'en ai jamais vu auparavant.
Lent par rapport à quoi? Je pense passer de l'ordinaire Ruby à JRuby (Ruby basé sur Java) parce que j'ai entendu dire que c'était plus rapide.
Les opinions sont des opinions et les faits sont des faits.
Voici un fait de Google Code Jam, qui met sans doute les programmeurs au défi de résoudre des problèmes informatiques difficiles dans un court laps de temps, ce qui signifie que les performances du langage qu'ils utilisent jouent un rôle important:
Lors des éditions précédentes (2009, 2010, 2011), environ 75% des programmeurs arrivés aux phases finales utilisaient C++, contre environ 15% avec Java.
Source -> http://www.go-hero.net/jam/
TMHO, cela est dû au temps nécessaire pour démarrer le VM dans le navigateur. Si une application démarre lentement, les gens ne s'en souviendront. Parce que, un temps de démarrage long est vraiment ennuyeux. Vraiment. Un de mon collègue m'a dit qu'il n'utilisait pas Firefox parce qu'il était trop lent. (?!?). Mais, oui, ok, sous Windows, Firefox met énormément de temps à apparaître. Selon lui, cette application est lente, il a fait son choix sur la vitesse générale de celui-ci.
Vers 1997, j'ai utilisé un HP Vectra VE (200 MHz) et Windows 95. La plupart des applications ont fonctionné très rapidement à ce sujet, mais j'ai ensuite essayé quelques applications écrites en Java (IDE, si je me souviens bien) Ils étaient très lents, du moins les parties de l'interface graphique. Ils ont mis du temps à démarrer et les éléments de l'interface graphique (par exemple les menus) n'étaient pas très réactifs - il y avait des retards dans le retour visuel. En outre, depuis Java Les applications GUI avaient (a) un look assez distinctif, j'ai appris à associer ce look (et Java) à de mauvaises performances.
Cela dépend de ce que vous entendez par lenteur.
Tout d'abord, Java comme cela a beaucoup progressé récemment et est très rapide dans la plupart des cas. Mais:
- Java est lent au démarrage, car vous devez charger la JVM avant de faire quoi que ce soit.
- Certaines fonctionnalités de sécurité peuvent tuer les performances dans certains cas. La vérification des liens avec accès aléatoire en est un exemple.
- Faites quelque chose de très rapide en Java nécessite de travailler contre la JVM (pour profiter de la ligne de cache par exemple).
- L'absence de métaprogrammation implique une pénalité au moment de l'exécution à chaque abstraction, ainsi les performances viennent au détriment de la conception dans de nombreux cas.
- Java peut difficilement garantir une contrainte de temps réel - par conception - et cela pourrait être considéré comme "lent" par certaines personnes.
Au fait, Java est, dans certains cas, plus rapide que Vanilla C/C++. Mais ces langages vous donnent les outils pour les modifier.
Java est un langage de programmation visant à la productivité. Maintenant, il est assez rapide pour la plupart des applications, mais pas suffisant pour d'autres.
En général, la lenteur de Java est un argument surutilisé car il est peu pertinent dans la plupart des cas.
Canonique simple Java tend à être égal ou plus rapide que le code canonique C/C++/D simple. Le code canonique simple a tendance à effectuer de nombreuses allocations de mémoire inutilement, ne pas être particulièrement réglé sur n'importe quelle architecture de processeur, pas de tonnes d'optimisations de bas niveau, etc. Le GC HotSpot de Java est tout simplement incroyable, et les optimisations VM ont tendance à être meilleures que ce qu'un compilateur statique pourrait faire.
D'un autre côté, si vous vraiment avez besoin de performances et êtes prêt à régler manuellement les choses pour les obtenir, C/C++/D offre beaucoup plus de possibilités pour cela. Vous ne pouvez pas utiliser l'assembleur en ligne en Java. Vous ne pouvez pas utiliser des astuces de punning de type sale pour traiter les nombres à virgule flottante comme des tableaux de bits. Vous ne pouvez pas utiliser des schémas de gestion de mémoire personnalisés qui peuvent être plus rapides que le GC pour votre cas d'utilisation spécifique. Vous ne pouvez pas allouer presque autant sur la pile en Java qu'en C/C++/D. En Java la seule façon d'obtenir quelque chose à peu près équivalent à les fonctions d'ordre supérieur sont avec les interfaces et la liaison d'exécution. En D et (je pense, corrigez-moi si je me trompe) C++, vous pouvez passer des fonctions aux modèles, permettant à la liaison de se produire au moment de la compilation sans perte de flexibilité.
Un autre point pour la "lenteur" de Java est le runtime 64 bits.
J'ai entendu des gens se plaindre que Java est très lent pour eux sur les ordinateurs 64 bits. Il s'avère que 64 bits Java runtime utilise le serveur JVM qui compile tout le programme avant de démarrer.
ICI explique pourquoi 64 bits VM démarre plus lentement.
Par exemple sous Windows:
C:\> Java -version
Java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
Pour jeter une pièce sans valeur, je trouve que Java webapps ont généralement de longs temps de démarrage et de réponse, où il me semble que Python ou Ruby aurait mieux fait.
J'utilise Eclipse pour la plupart de ma programmation, et je dois dire que Java est tout aussi rapide que toute autre chose, sinon plus rapide fonctionnant localement et "autonome").
La performance de Java est très subjective cependant, la perception de la raison pour laquelle Java est lente est en grande partie pour des raisons que d'autres ont noté: la perception de la plupart des gens de quelque chose est colorée) par leur expérience antérieure avec lui et Java n'a pas toujours été un langage bien optimisé sous le capot. De même, Vanilla Eclipse n'est pas exactement un rapide IDE pour travailler avec et pâlit en termes de réactivité par rapport à un IDE comme Visual Studio.
Cela dit, en dehors des problèmes d'interface utilisateur que Java a au démarrage, il est assez rapide pour la plupart des applications. Si vous recherchez, vous pouvez trouver articles qui le comparent avec d'autres langues et la plupart des résultats présentés le placent dans la plage où ce ne sera un problème que lorsque vous aurez affaire à des ensembles de données majeurs.
Dans le domaine de la bioinformatique, il est assez utilisé car il est bien pris en charge et il existe déjà une base d'installation pour, l'un des avantages de Java est que vous pouvez faire un développement assez rapide avec ce que vous ne pouvez pas faire avec C. Si vous regardez les langages utilisés pour la bioinformatique (j'utilise personnellement R, Python et Java régulièrement), vous remarquerez qu'aucun d'eux n'est exactement le plus rapide et il n'est pas inhabituel que les ensembles de données en bioinformatique se retrouvent dans les centaines de gigaoctets d'informations. En fin de compte, le temps humain est encore plus précieux et bien que les différences de vitesse soient perceptibles, la taille des ensembles de données ont tendance à être assez grands pour fonctionner de toute façon pendant la nuit.
S'il était plus facile d'écrire une interface utilisateur accrocheuse en Java c'est comme si la perception de la vitesse tombait du radar car la plupart des gens ne poussent pas suffisamment les langues pour que la vitesse soit vraiment un problème au quotidien base.