Pourquoi les gens disent-ils encore que Java est lent? [fermé]


61

Pendant longtemps à SO et ailleurs, Java a la réputation d'être lent. Qu'il s'agisse de blagues ou de nombreux commentaires dans les questions et réponses, les gens croient toujours que Java est lent, basé uniquement sur l'expérience acquise dans les années 90.

Ceci est mon problème: nous avons réfuté (la plupart) les raisons pour lesquelles les gens pensent que Java est lent. En dehors des petites choses, Java est assez rapide.

Alors, pourquoi les gens refusent-ils toujours de croire que Java est rapide maintenant? Cela fait-il partie de leur état d'esprit que tout ce qui n'est pas en 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 juste biaisés?


10
Umm, C # est rapide aussi;)
Evan Plaice

12
euh, ce lien ne réfute pas le fait que Java soit lent.

13
Mon sentiment est que Java est insensible plutôt que lent.
zneak

23
Bibliothèques d'interface utilisateur ballottées et horribles ..?
dmp

4
Parce que JVM ne fait pas partie du noyau. Oh, peut-être que des gars de Linux l'ajouteront à l'avenir.
Xiè Jìléi

Réponses:


131

Ce sont les applications. Comme vous le constatez, nous avons prouvé à maintes reprises que, dans des scénarios élaborés, le code Java peut atteindre ou même surpasser les performances de langages dits "performants" tels que C, C ++, Lisp, VB6 ou JavaScript. Et quand on leur présente de telles preuves, la plupart des adversaires sains et ouverts d'esprit craqueront pour la honte et promettront de ne plus jamais répandre une telle calomnie.

... mais ensuite, ils lancent Eclipse, ou NetBeans, ou Guiffy, ou activent la prise en charge de Java dans leur navigateur, ou tentent de faire fonctionner une application sur leur téléphone préféré. Et ils attendent que ça devienne réactif ...

... et attendez ...

... et attendez ...



... et attendez ...







... et attendez ...











... et ...




... qu'est-ce que je vous ai promis de ne plus jamais faire ? Désolé, doit avoir assoupi ...


44
Même la plus simple des interfaces graphiques Java prend au moins 1,5 seconde à démarrer. Ce n'est pas un petit peu.
Peter Boughton le

32
Je n'ai jamais pensé que Javascript était considéré comme un langage "performant".
zneak

11
+1 pour mentionner les IDE. Il y a une énorme différence entre la réactivité d'Eclipse et un IDE tel que Visual Studio.
mellowsoon

56
J'ai des problèmes avec cela. Firefox est écrit principalement en C ++ et son lent. Est-ce que cela signifie que C ++ est lent? Non, cela signifie que Firefox est lent. Dire qu'une langue est lente parce que le plus grand programme écrit est lent est stupide.
TheLQ

13
Jonas, utiliser l'exemple le plus simple que je puisse trouver ne fait pas de moi un mauvais programmeur. Si vous avez une méthode magique qui exécute une interface graphique Java en moins d'un clin d'œil, continuez et démontrez-la .
Peter Boughton

48

Cette question fonctionne sur de fausses prémisses: là où ça compte, Java est encore lent. Ce qui compte, ce sont les algorithmes très lourds en calcul sur de grands ensembles de données. Certes, ils peuvent être optimisés, parfois pour être à égalité avec le code C / C ++, mais uniquement au prix de la modularité et de la généricité. Un code C ++ efficace peut être conçu pour être générique et utilisable en tant que bibliothèque polyvalente. Le code Java ne peut pas. Il suffit de regarder la Array.sortméthode fortement optimisée , qui utilise différentes implémentations pour tous les types fondamentaux et dont la variante d'objet est encore beaucoup plus lente que le générique C ++, sortcar ces objets doivent envoyer des comparaisons d'égalité de manière dynamique.

Les optimisations accordées juste à temps, telles que effectuées par le moteur HotSpot, peuvent en fait prédire la cible de ces appels virtuels et tenter une insertion en ligne. Mais cela reste plus lent que l'appel directement intégré qui est distribué dans la sortméthode C ++ ' .

Un ancien collègue a fait des repères comparatifs d'un problème sur les ensembles de données énormes ( q -gram comptage en utilisant des formes dynamiques) avec une implémentation C ++ basé sur un modèle et une implémentation Java orientée objet. Le code Java était beaucoup plus lent que le code C ++.

Bien sûr, cela consiste à comparer des pommes avec des oranges. Mais le fait est que l'implémentation Java était la meilleure implémentation possible (en termes de performances, compte tenu du degré de modularité requis pour une bibliothèque), de même que l'implémentation C ++.

Malheureusement, les données de référence ne sont pas librement disponibles, mais d'autres ont trouvé des chiffres similaires lors de la comparaison des frais généraux liés à l'abstraction d'exécution. Par exemple, Scott Meyers écrit dans Effective STL à propos des frais généraux de la qsortfonction générique de C :

Le genre de C ++ embarrasse presque toujours le qsort de C quand il s'agit de vitesse. […] Au moment de l'exécution, la sorte effectue 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, [le type] a fonctionné jusqu'à 670% plus vite…


6
Pour être juste, std::sortest l’un des cas où il est difficile de faire la même chose dans d’autres langues. Mais la grande majorité des projets que j'ai vus ne correspond pas à un std::sortcode. Ils écrivent (mal) du code Java en C ++ et se plaignent d'avoir des problèmes.
Billy ONeal

2
Avez-vous des rapports pour sauvegarder votre récit selon lesquels des jeux de données volumineux sont lents? J'ai entendu des gens parler de faire des opérations entre 1 et 2 millions de listes d'entrée et que cela reste rapide. Et jouer avec des jeux de données massifs en mémoire (généralement dans une base de données, par exemple) n’est-il pas un créneau?
TheLQ

8
@TheLQ: la source est le livre SeqAn de Gogol-Döring & Reinert. Et à propos de votre contre-exemple: quelles opérations? Et qu'est-ce qu'ils considèrent comme "rapide"? De plus, les entrées 1E6 ne sont pas si volumineuses. ;-) Et quant à savoir s’il s’agit d’un domaine de niche - certainement. Mais c’est là que vous avez besoin de calculs rapides. Le problème est de savoir si Java est rapide , et non pas «suffisamment rapide» pour des opérations peu coûteuses. Sur un ensemble de données suffisamment petit, tout est suffisamment rapide.
Konrad Rudolph

2
il n'y a pas de meilleure implémentation possible
jeremy-george

3
@fonzo Il peut y avoir des approximations raisonnables. Grattez cela, pour un algorithme assez simple et une métrique bien définie, il peut y avoir une meilleure implémentation possible. C'est le cas ici. L'algorithme est simple et il existe un cas bien défini pour lequel l'optimisation a été: le temps d'exécution sur une entrée donnée.
Konrad Rudolph

28

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 est considérée comme lente.

D'autre part, si vous utilisez un serveur, peu importe s'il y a un échauffement (analyse et compilation JIT) - vous le faites une fois dans Blue Moon, si bien que la plupart du temps, cela ne peut pas être considéré comme tout à fait lent.


Les coûts de démarrage sont un problème, mais vous pouvez le modifier avec des commutateurs de ligne de commande
TheLQ

22
Combien d'utilisateurs connaissent réellement les commutateurs de ligne de commande?
Walter le

17
TheLQ, si vous pouvez fournir un commutateur de ligne de commande pour supprimer le délai de démarrage de 1.5s pour Swing / AWT, répondez s'il vous plaît et répondez ceci: stackoverflow.com/questions/508723/…
Peter Boughton le

6
Et comment puis-je modifier ces commutateurs de ligne de commande pour éviter que le navigateur entier ne se bloque pendant 5 secondes si je clique sur un lien contenant un élément Java? C'est le genre de chose qui fait que Java est appelé lent, et peu importe qu'une fois chargé, il s'exécute assez rapidement.
Roman Starkov

21

Je dirais que c'est parce que quand les gens l'ont rencontré pour la première fois, c'était lent. Sur cette base, ils en ont eu une impression. Cette impression est peu susceptible de changer si ils ne l'utilisent pas, et ils ne l'utilisent pas à cause de cette impression - c'est un cercle vicieux.

Je dois avouer que j’ai eu l’impression que Java était lent, et c’est bien ce qui m’était dû à mes précédentes expériences. Je suis maintenant passé à différentes langues et mon exposition à Java est extrêmement limitée depuis. Par conséquent, mon opinion n'a pas beaucoup changé.


3
+1 - Je suis totalement d'accord. Je détestais Java à ses débuts. Le .NET Framework a vraiment aidé le code managé: j’aimais bien le C # et j’appréciais aussi Java.
Wizard79

7
Il faut encore une seconde pour lancer hello world. C'est lent en termes de temps de démarrage.
Intuition le

@intuited Essayez de créer un serveur via C ++ / C # ou tout autre langage que vous pourriez trouver. HECK essayez de le construire avec C et THEN en le comparant à JAVA. Le truc avec C, c’est que c’est rapide si vous êtes un type. Le moment où votre code C augmente, votre vitesse ralentit;)
AceofSpades

16

Parce qu'il faut une génération pour changer la perception des gens sur un produit

Cela n'a rien à voir avec la rapidité avec laquelle Java devient. Dans l'esprit des gens, Java est un identifiant constant associé au mot "slow". Il n'y a rien, ni vous ni Oracle ne pouvez y remédier.

Soyons heureux que Oracle n’ait pas encore détruit la culture de la programmation Java en faisant des choses téméraires ou stupides . Comme facturer des coûts de licence excessifs pour l'utiliser. Ou poursuivre des personnes sur la base de brevets logiciels précédemment détenus par Sun. ::soupir::

Je déteste être le naysayer ici, mais, à moins que Oracle et Google ne règlent les problèmes de Java, ou que Google soit obligé d'acheter Java et d'en faire une plate-forme open source «appropriée», Java est en passe de devenir le gosse. 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 parle de génération, je parle en termes humains et non en termes informatiques. En d’autres termes, 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 reste vraie. Pensez en termes de 5 décennies et non de 5 ans.


2
Je pense que Google utilise tellement de Java que leur achat n’est pas une théorie totalement infaisable. Je serais probablement heureux avec ça.
Bart van Heukelom

1
@donroby: Et qui se soucie de ces langues? Dans deux décennies, Java sera un langage de niche.
Aasc

1
@aasc - Java sera peut-être obsolète dans deux décennies, mais LISP n'est pas maintenant et ne le sera plus.
Don Roby

2
@aasc "Les langages de programmation ne vivent généralement pas plus d'une génération" Bon Dieu, 1 million de développeurs Delphi c'est Pascal, 5 millions de développeurs Visual Basic err ... sans oublier Perl, Lisp, Fortran, Cobol, C ++ aucune justification pour ce commentaire ???
Reallyethical

2
@ Reallyethical Pas dans les grandes lignes. Combien d'entreprises dépendent de Lisp, Fortran, Cobol. Avec lisp, il est principalement piégé dans les universités et utilisé comme modèle pour les fonctionnalités d'autres langues, peu l'utilisant pour des projets de production réels. Fortran est devenu un langage de niche pour la modélisation mathématique hautes performances et Cobol ne subsiste que parce que le secteur bancaire a très peur de changer son code ancien / fiable en une nouvelle plate-forme. C ++ est l'exception flagrante car il est encore très largement utilisé et adopté aujourd'hui.
Evan Plaice

11

Une des raisons est que les gens font confiance à ce que les autres disent plutôt qu’à ce qu’ils voient .

D'après ce qu'on m'a dit quand j'ai commencé à programmer, Java est "plus lent" que le C ++, et la raison pour laquelle Java pourrait être utilisé est parce que c'est "pratique et plus facile". Il est communément admis que Java apporte sécurité et commodité, au détriment des performances. Même quand plus tard C # est inventé, les gens pensent que c'est plus rapide que Java parce que c'est "natif".

Mais la vérité que les gens voient sans le savoir, c’est que, Eclipse, l’EDI construit avec Java, est absolument l’IDE ​​le plus rapide de sa classe. J'ai utilisé presque tous les IDE du flux principal, ceux de MS et de GNU, Borland ..., eclipse est le roi absolu des IDE, en grande partie grâce à sa rapidité.

Une autre raison est son long temps de démarrage .

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, ouvre 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 toujours présent, pour optimiser l'utilisation de vos ressources informatiques et répondre à des millions de demandes toutes les heures. Ou un IDE comme eclipse qui gère des milliers de fichiers d'espace de travail. Vous ne savez pas que votre application Java est rapide jusqu'à ce qu'elle ait fonctionné pendant au moins plusieurs heures, je crois.


1
Je vois la lenteur tout le temps.
aasc

28
Eclipse rapide? LMAO
finnw

2
@finnw - c'est si vous l'accordez. Hors de la boîte et avec tous les plug-ins, évidemment ce ne sera pas rapide. Évidemment, cela ne peut jamais être comparé à vim, jedit ou Notepad ++, mais ces arguments et déclarations "rapides" ou "lents" n'ont pas de sens sans contexte.
luis.espinal

2
@luis, vous pouvez toutefois le comparer à Delphi 7, qui, à mon avis, n’est pas aussi simple que Eclipse. Et Delphi 7 est presque aussi rapide que le bloc-notes. C'est fou.
Roman Starkov

4
@finnw, pour un IDE avec des zillions de plugins, c'est plutôt rapide :)

8

@bigown "Pourquoi les gens disent-ils encore que Java est lent?"

Parce qu'ils sont bêtes. Parce qu'ils n'ont aucune expérience professionnelle, 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 telle chose retardée sont nombreuses, mais habituellement, la stupidité, le fanboyisme subjectif aveugle, et l'attention prostituée émotionnelle semblent être derrière eux.

Voyons cela pour que vous puissiez voir la vérité sur ce que je viens de dire ci-dessus:

Premièrement, qu'est-ce qui est lent, dans quel contexte, pour quoi, dans quelles conditions, avec quel objectif d'ingénierie / scientifique / d'entreprise (dire que ça craint n'en est pas un.) Toute personne qui dit que "X est lent" pour toute technologie X, ou simplement "X est Y" où Y est un type d'affirmation négative, sans répondre à aucune des questions ci-dessus devrait être rejeté comme un imbécile. De telles déclarations n'ont pas leur place en ingénierie. En politique et dans les forums de discussion pour mineurs peut-être, mais pas en ingénierie.

Deuxièmement, la plupart de ces imbéciles égarés se plaignent de la lenteur de Java car ZOMG, leur éclipse prend une éternité à se déclencher (gee, chargez la chose avec tous les plug-ins et devinez ce qui se passe.) La plupart de ces imbéciles ne savent même pas comment pour régler le jvm afin qu’éclipse fonctionne rapidement (ou pour n’importe quelle application Java). Autrement dit, ils n’ont aucune idée du réglage des performances, ce qui est une réalité non seulement pour Java, mais pour tout système non trivial, qu’il s’agisse de matériel ou de logiciel. Donc là, ils se désarment de toute validité technique pour faire de telles déclarations insensées.

Troisièmement, considérons l’essentiel du développement Java: le back-end OLTP en premier lieu; systèmes de surveillance à venir en second. L'un ou l'autre type de système est destiné à fonctionner en grappes et à fonctionner sans interruption pendant des semaines, voire des mois. Est-il vraiment important que votre petite application éclipse ou jouet prenne une minute ou deux à charger lorsque le but des applications Java REAL est de fonctionner pendant de longues périodes? Contexte, personnes, contexte.

Enfin, l’épine dorsale d’OLTP sur Google et Ebay fonctionne sous Java. Je considérerais cela comme une preuve contradictoire du fait que Java n’est pas lent (du moins pour les conditions qui importent, pas pour les petites expériences de jouets, les repères et les preuves invérifiables 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 les déclarations comme celles appartiennent?


19
Si je dois optimiser ma machine virtuelle Java pour que Java s'exécute rapidement, alors que je n'ai rien à régler (à l'exception de -O2) pour que C ++ s'exécute rapidement, Java est lent.
David Thornley

@ David - Déclaration évidente. Tout le monde sait que Java est plus lent que C ++. Cela ne signifie pas logiquement que c'est lent, cependant. Aucune mention des drapeaux gcc ne donne la validité du commentaire. Il indique seulement qu'un it is slower than something else.jaguar est plus lent qu'un guépard. Cela fait-il l'ancien slow? Essayez une objectivité technique et posez-vous la question suivante: peut-on déclarer logiquement arbitrarilyque quelque chose est slowsimplement parce it is slowerque quelque chose d'autre without mentioning a context of operationsdéfinit ce qui est fast enoughet pour quoi? Pouvez-vous, logiquement?
luis.espinal

5
@ luis.espinal: Je répondais à votre raison n ° 2: les gens disent que Java est lent car, à votre avis, ils n'ont pas réussi à adapter Java. Veuillez également noter mon utilisation de "rapidement acceptable". Il me semblerait que quelque chose qui n'est pas "assez rapidement" est lent, et il me semble que quelque chose que les gens prétendent couramment est lent n'est probablement pas assez rapide.
David Thornley

4
@luis espinal Vous parlez comme Kant :) Les gens ici ont supposé implicitement que lent signifie moins vite que d'autres langages pratiques prêts à la production tels que C ++. (Rappelez-vous la physique ??) Lorsque vous mesurez l'énergie potentielle, vous la mesurez toujours par rapport à un sol. En ce qui concerne votre grammaire, "X is dumb" est sans fondement. et "X est plus bête que Knuth" ne fait pas de X un idiot absolu, car quasiment tout le monde peut être X ici. Je suis d’accord pour dire que c’est une langue, ce n’est pas une élite, mais les gens ici qui disent que ce n’est pas «stupide», mais qui ont juste formulé une hypothèse implicite convenue.
Yati Sagade

1
@luis hahaa .. belle observation. (Ma conviction que vous êtes une réincarnation de Kant est devenue encore plus solide;)) Et de telles discussions aboutissent à des guerres à la flamme et à des frappes au clavier improductives ... Selon moi, il faut toujours s'en tenir à ce qui semble être le meilleur outil pour s'attaquer le travail à portée de main. D'accord, Kant2? : P
yati sagade

8

Parce que c'est le cas, pouvons-nous fermer 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 effectuées par les employés de Google]

PS: Si ce n’est pas le cas, nommez-moi au moins une application jappée Java, mais n’en avez jamais vu une auparavant.


6
Veuillez résumer le contenu du PDF dans votre réponse.
Adam Lear

1
Ce document est très loin des normes de recherche scientifique. Il ne compare même pas exactement les mêmes algorithmes et optimisations dans toutes les langues. "E. Java Tunings Jeremy Manson a présenté les performances de Java sur un pied d'égalité avec la version C ++ d'origine. Cette version est conservée dans le répertoire java_pro. Notez que Jeremy a délibérément refusé d'optimiser davantage le code. De nombreuses optimisations C ++ s'appliqueraient à Java version aussi bien. " jeremymanson.blogspot.com/2011/06/scala-java-shootout.html
Piotr Kolaczkowski

6

TMHO, cela est dû au temps nécessaire au démarrage de la machine virtuelle dans le navigateur. Si une application commence lentement, les gens ne s'en souviendront plus. Parce que le temps de démarrage long est vraiment ennuyeux. Vraiment. Un de mes collègues m'a dit qu'il n'utilisait pas Firefox car il est trop lent. (?!?) Mais, oui, d'accord, sous Windows, Firefox met énormément de temps à apparaître. Selon lui, cette application est lente, il a pris une décision concernant sa vitesse générale.


C'est pourquoi Mozilla a déployé beaucoup d'efforts pour que Firefox démarre rapidement ...
Spudd86

2
Cela pourrait ressembler à Windows. Oui, après vous être connecté, vous voyez le bureau très rapidement, mais vous devez encore attendre un moment pour qu'il soit réactif.
Bart van Heukelom

6

Lent par rapport à quoi? Je pense passer de Ruby ordinaire à JRuby (rubis basé sur Java) car j'ai entendu dire que c'était plus rapide.


1
JRuby est plus rapide que Ruby, même en 1.9. Cependant, l'écart se réduit.
Dan Rosenstark

2
+1 pour avoir signalé un gros problème. Bien que je dirais que l'OP est probablement en train de se comparer à C # ou C ++.
Billy ONeal

@Yar, vous indiquez que CRuby rattrape JRUby?

6

Les opinions sont des opinions et les faits sont des faits.

Voici un fait tiré de Google Code Jam, qui incite sans doute les programmeurs à résoudre rapidement des problèmes informatiques complexes, ce qui signifie que les performances du langage utilisé jouent un rôle important:

Lors des éditions précédentes (2009, 2010, 2011), environ 75% des programmeurs arrivés aux phases finales utilisaient le C ++, contre environ 15% utilisant Java.

Source -> http://www.go-hero.net/jam/


3
Cela prouve vraiment que Java peut se hisser au sommet d’une concurrence axée sur la vitesse, mais la plupart des gens choisissent le C ++.
Adam Lear

3
"résoudre des problèmes informatiques difficiles en peu de temps" - quoi, le temps nécessaire pour écrire le code ou le temps nécessaire à son exécution ? Quoi qu'il en soit, votre fait est que - un fait - qu'est-ce que cela a à voir avec la question? Tirez-vous une conclusion de votre fait?
occulus le

ce qui s'explique peut-être simplement par le fait que 75% des personnes qui écrivent des programmes qui achèvent les derniers tours pensent que Java est lent sans l'avoir déjà testé et utilise donc le C ++ à la place, car ils croient que c'est rapide sans l'avoir jamais testée.
Jwenting

4

Vers 1997, j’utilisais un HP Vectra VE (200 MHz) et Windows 95. La plupart des applications tournaient très vite sur ce point, mais j’ai ensuite essayé quelques applications écrites en Java (IDE, si je me souviens bien). Ils étaient très lents, du moins l’interface graphique. Le démarrage a pris beaucoup de temps 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. De plus, les applications Java ayant une apparence assez distinctive, j’ai appris à associer cette apparence (et Java) à de mauvaises performances.


2
Je me souviens de 1997! Grande année, même si beaucoup de vins - et observations - de 1997 ne sont plus utilisables.
Dan Rosenstark

1
Je me souviens bien de 1997 aussi. Windows se bloquait constamment et nécessitait un redémarrage pour installer un pilote. Morceau de ferraille.

Et vous n'avez pas changé votre opinion de 1997? Avez-vous remarqué que 2011 est totalement différente de 1997?
Jesper

5
Mon analyse à partir de ces données serait que 1997 était nul.
JasonTrue

4

Cela dépend de ce que vous entendez par lenteur.

Tout d’abord, Java a récemment fait de nombreux progrès et est très rapide dans la plupart des cas. Mais :

  • Java est lent au démarrage, car vous devez charger la machine virtuelle avant de faire quoi que ce soit.
  • Certaines fonctions de sécurité peuvent tuer des performances dans certains cas. Le contrôle lié avec accès aléatoire est un exemple.
  • Faire quelque chose de très rapide en Java nécessite de travailler contre la JVM (pour tirer parti de la ligne de cache par exemple).
  • L'absence de métaprogrammation implique une pénalité au moment de l'exécution à chaque abstraction, de sorte que les performances sont souvent au détriment de la conception.
  • Java peut difficilement assurer une contrainte de temps réel - de par sa conception -, ce qui pourrait être considéré comme «lent» par certaines personnes.

En passant, java est, dans certains cas, plus rapide que la vanille C / C ++. Mais ces langues vous donnent les outils pour les ajuster.

Java est un langage de programmation destiné à la productivité. Maintenant, il est assez rapide pour la plupart des applications, mais pas assez pour d'autres.

En général, la lenteur de Java est un argument surutilisé, car elle est dans la plupart des cas irréprochable.


2

Le code Java simple et canonique a tendance à être égal ou plus rapide que le simple code C / C ++ / D canonique. Le code canonique simple a tendance à effectuer beaucoup d’allocations de mémoire inutilement, à ne pas être particulièrement adapté à une architecture de processeur, à ne pas avoir à faire des tonnes d’optimisations de bas niveau, etc. Le HotSpot GC de Java n’a rien d’étonnant, et les optimisations de VM d'être meilleur que ce qu'un compilateur statique pourrait faire.

D'autre part, si vous avez vraiment besoin de performances et que vous êtes prêt à ajuster les choses pour les obtenir, le C / C ++ / D offre de nombreuses autres possibilités à cet égard. Vous ne pouvez pas utiliser l'assembleur inline en Java. Vous ne pouvez pas utiliser d’astuces de frappe de type sale pour traiter les nombres à virgule flottante comme des tableaux de bits. Vous ne pouvez pas utiliser de schémas de gestion de la mémoire personnalisés pouvant être plus rapides que le CPG 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, le seul moyen d'obtenir quelque chose d'équivalent à peu près aux fonctions d'ordre supérieur est d'utiliser des interfaces et des liaisons d'exécution. En D et (je pense, corrigez-moi si je me trompe) en C ++, vous pouvez transmettre des fonctions aux modèles, ce qui permet la liaison au moment de la compilation sans perte de flexibilité.


5
Pouvez-vous vous procurer ces commentaires? C'est-à-dire, où des points de repère montrent-ils du code canonique dans chaque langue montrant que Java est plus rapide?
Billy ONeal

1

Un autre point pour la "lenteur" de Java est le runtime 64 bits.

J'ai entendu certaines personnes se plaindre du fait que Java est très lent sur les ordinateurs 64 bits. Il s’avère que le runtime Java 64 bits utilise une machine virtuelle Java pour serveur qui compile l’ensemble du programme avant de démarrer.

ICI explique pourquoi la machine virtuelle 64 bits 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)  

3
La VM du serveur est plus lente à démarrer mais elle ne compile pas nativement le programme complet avant de démarrer. Cela n’était pas possible, les classes sont chargées paresseusement et potentiellement par réflexion, il n’ya donc aucun moyen de savoir à l’avance quel code intermédiaire doit être compilé en mode natif.
Dan Dyer le

@Dan Dyer Après quelques recherches, j'ai mal compris ce que j'ai lu. Je voulais dire que Server VM optimise davantage tandis que le client est optimisé pour un démarrage rapide et une utilisation réduite de la mémoire.
AndrejaKo

La machine virtuelle du serveur est optimisée pour les processus de longue durée. Par conséquent, le préchargement est plus important, ce qui entraîne des temps de démarrage plus longs et une utilisation plus importante de la mémoire vive. La machine virtuelle client est optimisée pour réduire l'encombrement et les temps de démarrage, mais les performances d'exécution peuvent être moindres.
Jwenting

0

Les performances de Java sont très subjectives, cependant, la raison pour laquelle Java est lent repose en grande partie sur des raisons que d'autres ont déjà notées: la perception de la plupart des gens est colorée par leur expérience antérieure et Java n'a pas toujours été un langage bien optimisé. la hotte. De même, vanilla Eclipse n’est pas vraiment un IDE rapide avec lequel travailler et une réactivité médiocre par rapport à un IDE comme Visual Studio.

Cela dit, en dehors des problèmes d’interface utilisateur posés par Java au démarrage, il est assez rapide pour la plupart des applications. Si vous effectuez une recherche, vous pouvez trouver des articles qui le comparent à d'autres langues et la plupart des résultats présentés le placent dans la fourchette où il ne sera problématique que si vous traitez avec des ensembles de données importants.

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. L’un des avantages de Java est qu’il permet un développement assez rapide avec celui que vous ne pouvez pas utiliser 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'entre eux n'est exactement le plus rapide et qu'il n'est pas inhabituel que les ensembles de données en bioinformatique atteignent les 100 de gigaoctets d'informations. En fin de compte, le temps humain est encore plus précieux et, même si les différences de rapidité sont perceptibles, la taille des ensembles de données a tendance à être assez grande pour qu’ils durent toute la nuit.

S'il était plus facile d'écrire une interface utilisateur vive en Java, c'est plutôt comme si la perception de la vitesse disparaissait du radar, car la plupart des gens ne poussent pas suffisamment les langues pour que la vitesse soit réellement un problème quotidien.


0

Pour ajouter une pièce sans valeur, je constate que les applications Web Java ont généralement de longs temps de démarrage et de réponse, où il me semble que Python ou Ruby auraient fait mieux.

J'utilise Eclipse pour la majeure partie de ma programmation, et je dois dire que Java est aussi rapide que tout le reste, sinon plus vite en local et "autonome".


1
Sur le Web, le temps de démarrage n’est pas aussi important. C'est la consommation de ressources et l'évolutivité qui comptent le plus.
Berin Loritsch

-7

Je dirais que Java est infiniment lent, pas seulement lent, car il ne résout pas les problèmes simples qui sont faciles dans les langages de haut niveau.

Laissez-moi vous donner un exemple simple. Il y a une optimisation simple qui s'applique lors du mappage d'une liste deux fois, appelée déforestation: voici la règle pour qu'elle soit écrite dans ma langue Felix:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

qui dit: au lieu de mapper la liste x avec f, puis de la mapper à nouveau avec g, nécessitant deux traversées de liste et créant une liste temporaire de déchets, mappez simplement la liste avec la composition des fonctions.

Il s’agit d’une optimisation de haut niveau bien plus importante que les performances de bas niveau de la machine virtuelle Java. La spécification que j'ai donnée ci-dessus n'est pas simplement une jolie syntaxe, il s'agit d'une instruction écrite par l'utilisateur qui indique au compilateur Felix comment effectuer une optimisation.

S'il vous plaît, montrez-moi comment faire ce genre de chose en Java. Non? Alors Java est lent. Très lent. [Haskell peut faire cela automatiquement, je crois].

Et avant de dire "mais Java est un langage OO, ce type d'optimisation ne s'applique pas" ... eh bien, c'est exactement ce que je veux dire. Java craint, et être OO est l'une des principales raisons.

L’optimisation JIT ne peut jamais rivaliser avec les types d’optimisation que peut faire un compilateur décent.


3
Je n'ai absolument aucune idée de ce que votre code y fait. Et si vous dites qu'une langue entière est lente simplement parce qu'elle ne peut pas faire une petite optimisation, alors il y a d'autres problèmes ici
TheLQ

7
-1 creuser une vieille question et dénigrer une langue avec des arguments très boiteux. Dites-moi si vous voulez une description détaillée de ce qui ne va pas avec votre raisonnement. Pour commencer, dire que OO est la raison principale pour laquelle ça craint n'est pas très objectif et les performances de facto d'une JVM + JIT sont très bonnes, même s'il reste des optimisations.

8
Haskell est infiniment plus lent que Java pour notre plate-forme principale, car il n'est pas porté sur cette plate-forme, donc Haskell est nul ...

1
@ Thorbjørn Ravn Andersen J'aimerais vraiment pouvoir vous donner un +1 pour cette observation.
Patrick Hughes le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.