[F] Java : ça rame ou ça rame pas ? - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, suivez ce lien.

( hum, tu as déjà vu un soft codé en Java ? )

Déjà en Java, la bibliothèque graphique est, en grande partie, en Java. Donc la situation n'est pas vraiment comparable avec un moteur en C++ très optimisé.

Mais le principal problème avec les GUI en Java, ça n'est pas le langage lui même, mais surtout l'API qui est mal foutue. Elle parait assez simple au premier abord mais si on ne fait pas très attention on se retrouve facilement à bloquer/ralentir le thread dédié à l'affichage et on a une interface non réactive.

Y'a pas que ça, l'implémentation est aussi à la ramasse, suffit de voir le temps que met Java pour démarrer et la quantité de RAM qu'il bouffe...

En fait en terme de Java, la conso memoire ne doit pas etre si important, le probleme c'est que java est un OS dans l'OS, et un OS se reserve de grosses zones de memoire, meme si elle ne sont pas utilise...

Vous avez des exemples d'interfaces de programmes java qui rament ? Juste pour que je me rende compte.
Quant à la mémoire, je n'ai pas l'impression que ce soit tellement significatif, franchement. Par exemple mon visual ne prend pas moins que mon eclipse (jdt), et les fonctionnalités sont pourtant en retrait (solution c++)

Jsais pas, à peu près n'importe quoi qui est produit avec : Eclipse, IntelliJ, NetBeans, etc.
Après la particularité de ces IDEs c'est aussi de te bouffer toute ta RAM (ou la moitié si t'en as bcp), et avec en général un serveur d'application qui lui te bouffera également toute la mémoire (qu'il ne reste plus à cause de l'éditeur) ou la seconde moitié si t'en as bcp, ça donne une impression de ramage légèrement exacerbée il est vrai, dépassant la simple consommation CPU.

Jira, meme si l'IHM est en html est un bon exemple de truc en java qui rame..

Sous eclipse, l'interface est lente avec un PC normal ? Sérieusement tu vois une différence avec visual ? Tu fais un CTRL+h, ta fenêtre est lente à arriver ?
Eclipse ne risque pas de bouffer plus de RAM que ce que tu lui as autorisé de prendre (genre 1go par défaut je crois)
En plus on compare tout et n'importe quoi : quel rapport entre java et ton serveur d'application j2e qui tourne en arrière plan ?

T'as demandé des exemples de programmes Java qui rament, on t'en a donné

Je trouve Eclipse super lent, même avec une très grosse machine et en lui laissant pas mal de RAM.

Godzil > connais pas, je regarderai. Merci. (Mais bon interface en HTML... ?!)
Flanker > lent pour faire quoi, par rapport à quel logiciel ?

Brunni (./2604) :
Jsais pas, à peu près n'importe quoi qui est produit avec : Eclipse, IntelliJ, NetBeans, etc.Après la particularité de ces IDEs c'est aussi de te bouffer toute ta RAM (ou la moitié si t'en as bcp),

Sauf qu'ils rament quand même moins (du moins chez moi) que Visual Studio qui est l'équivalent en natif. Les IDE d'aujourd'hui sont tous très lourds car ils font beaucoup de chose, c'est pas une spécificité de Java.
A l'opposé, si tu compare JEdit à Notepad++ tu verras que les deux sont très rapide.

Godzil (./2605) :
Jira, meme si l'IHM est en html est un bon exemple de truc en java qui rame..

Bah la c'est une Appli Web alors qu'on parlait de responsivité de l'IHM d'un navigateur. Y'a 1000 raison autre que Java qui peuvent faire que ça rame. Je bosse avec plein d'appli web Java qui ne rament pas plus que les équivalent C#, PHP, ...

Uther > et encore, visual c++ (2010) est à des années lumières d'éclipse jdt (en c# ça a l'air mieux par contre)

(Éventuellement, le truc qui est sensiblement plus lent qu'avec certains programmes natifs c'est d'ouvrir tous les menus en glissant la souris dessus à grande vitesse -- là OK, il y a une différence ressentie )

On a manifestement des expériences différentes avec Visual Studio et Eclipse respectivement. Probablement qu'on n'utilise pas la même chose, qu'on n'a pas les mêmes plugins (dans mon cas je n'ai que Visual Assist X et un thème). Mais pour ma part Eclipse est lent (= ma définition de "rame") de base. Il devient juste ultra lent avec un serveur d'application, mais je le précise parce que c'est pas du jeu, c'est juste que c'est l'utilisation que je fais d'Eclipse en général (ça ou de l'Android, aussi lent comme la mort par la cuiller) donc évidemment ça empire ma perception.

Et ne parlons pas dandroid studio...

Oui, je mettais ça dans la catégorie IntelliJ.
Là aussi Android Studio n'est pas lent strictement à cause de Swing ou de l'UI elle-même, mais à cause de l'intégration de gradle super lourde qui bouffe tous tes cores CPU, ralentissant l'interface comme au temps des mainframes, et des locks interthreads qui jouent sur l'UI, et du fait que parfois cette dernière semble attendre le résultat de certaines opérations de façon synchrone. Bref au final *ça rame* et *c'est fait en Java*. Oui il y aurait à chercher plus loin (genre c'est pas la faute de Java si les dévs d'intellij codent mal leur UI), mais je pense que pour 99% de la population c'est une conclusion logique. En effet si tu pars là-dessus les dévs d'intellij codent mal, mais en fait aucun codeur Java ne code bien les UIs. Trop facile.

Il faut dire que Swing est fait de telle sorte que c'est facile de bloquer/ralentir l'EDT.
On peut bien coder en Swing mais c'est tellement facile de laisser du code potentiellement lent s’exécuter dans ce thread que sur une grosse application on fini par le faire volontairement ou non. Faire du Swing réactif c'est possible mais c'est tellement chiant que presque personne ne le fait. C'est pas pour rien que Oracle essaye de le faire disparaître.

En l'occurence, Jira rame non pas a cause du navigateur, mais bel et bien a cause du code en java derriere, pour avoir fait des tests sur une machine DEDIE a Jira avec juste jira qui tourne par dessus un linux minimaliste, en reseau local et peux d'utilisateurs, ca rame.

Non, Jira ramait (limite inutilisable) pas à cause de java mais à cause d'une gestion de BDD moisis.
Ici, depuis que l'on est passé sur une version plus récente avec refonte et optimisation des requêtes, ça répond quasi instantanément.

Recente == quelle version? (quand j'ai fait ces test c'etait il y a grosso modo 2 ans.. (putain le temps passe...))

Brunni (./2613) :
On a manifestement des expériences différentes avec Visual Studio et Eclipse respectivement.

Manifestement

Brunni (./2613) :
Probablement qu'on n'utilise pas la même chose

Mais justement, tu utilises quoi qui est lent à réagir ? Quelle fonctionnalité ? Quel bouton te fait attendre son résultat ? Quel fenêtre tarde à apparaître ?

Brunni (./2613) :
qu'on n'a pas les mêmes plugins (dans mon cas je n'ai que Visual Assist X et un thème).

J'utilise eclipse JDT de base (eclipse for java developper), avec notamment le plugin Window builder (intégré de base aussi)
Quant à Visual, j'utilisais aussi Visual Assist X, qui était pas mal mais loin d'eclipse quand même niveau robustesse (le refactoring n'est pas très malin et se trompe facilement).

Uther (./2616) :
Il faut dire que Swing est fait de telle sorte que c'est facile de bloquer/ralentir l'EDT.
On peut bien coder en Swing mais c'est tellement facile de laisser du code potentiellement lent s’exécuter dans ce thread que sur une grosse application on fini par le faire volontairement ou non.

Euh, c'est légèrement normal que l'interface soit bloquée si le codeur bloque le thread de swing ?!

Pen2: il y a de forte chances que le JDT soit un peu mieux ecrit que le CDT qui est une affrosité, un vrai monstre de lenteur...

Pen^2 (./2603) :
Vous avez des exemples d'interfaces de programmes java qui rament ? Juste pour que je me rende compte.

Bha, *à chaque fois* que j'ai vu un soft en Java, il ramait (plus ou moins). Je ne vais citer personne ici mais y'a des logiciels métier vraiment... hum.... enfin bon le genre tu as un dual core et tu regrette la fluidité des ordis des années 80

Bon maintenant est-ce que c'est du à 1)Java ou 2)certains codeurs Java, je pense que 1) n'est pas top mais que le gros problème est probablement 2).

Godzil (./2621) :
Pen2: il y a de forte chances que le JDT soit un peu mieux ecrit que le CDT qui est une affrosité, un vrai monstre de lenteur...

J'ai toujours lu que CDT était merdique, mais qu'il s'était amélioré quand même. Mais je n'ai jamais essayé.

very (./2622) :

Pen^2 (./2603) :
Vous avez des exemples d'interfaces de programmes java qui rament ? Juste pour que je me rende compte.

Bha, *à chaque fois* que j'ai vu un soft en Java, il ramait (plus ou moins). Je ne vais citer personne ici mais y'a des logiciels métier vraiment... hum.... enfin bon le genre tu as un dual core et tu regrette la fluidité des ordis des années 80

Bon maintenant est-ce que c'est du à 1)Java ou 2)certains codeurs Java, je pense que 1) n'est pas top mais que le gros problème est probablement 2).

Oui mais bon, plein de logiciels métiers sont en interface DOS et tout moisis, probablement en C ou C++, est-ce qu'on doit blâmer ces langages ?
Donc, je penche vraiment pour 2) moi aussi.



Sinon, la première fois que j'ai utilisé eclipse c'était à l'école, sur des vieux Pentium pourris en salle de TP (qui furent changés juste après).
OK, là, je confirme que j'ai eu une très mauvaise première impression

C'est une constante que je remarque : quand il y a un problème dans un logiciel Java, tout le monde a tendance à accuser Java, alors que s'ils ont le même problème dans un logiciel écrit dans un autre langage, même s'il est techniquement bien moins rapide/sécurisé/... que Java, c'est au mieux le développeur du logiciel qui est visé.

Je ne dit pas que Java n'est pas critiquable, loin de là, mais 90% des critiques qu'il reçoit ne sont pas particulièrement justifiés.

Je ne supporte plus Netbeans, il rame bien trop souvent.
Tout ça parce qu'il a 6 ou 7 projets d'ouvert à la fois, avec un paquet de fichiers ouverts à la fois, et une flopée d'addons installés, le tout en gardant mon Firefox (et ses 30+ onglets d'ouvert) sur mon PC pro avec ses larges 4Go de RAM.
Bouh Java !

la plupart du temps c'est effectivement le code qui est mal fait.
Sur une appli java+C sur laquelle j'ai travaillé, en passant d'une vieille machine de plus de 10 ans à une toute nouvelle, en résultat on a x10 sur la vitesse de traitement en C, et difficilement un x2 sur le java en faisant aucune modif.

Un des traitements java le plus gourmand mettait 15min sur la nouvelle machine, après étude et correction de l'algo, le traitement se faisait en moins de 1s... pour dire à quel point c'était mal foutu...

le problème est aussi que ces logiciels se veulent modulaires (OSGI, machin équivalent dans netbeans).

Du coup absolument tout est configurable et extensible par plugin, par contre bonjour les performances, tout est généralisé et non optimisé.