Qu'est ce qui rame ... donne des exemples ...
avec quoi comme VM, comme comme parametre de GC (mode incremental, clean/mark/sweep)....
Si t'as un iPAQ sous la main, met SavaJeXE et je n'aurais pas besoins de te convaincre ....
L'un des PB de Swing etait la conso memoire mais avec la 1.4 il va directement pioché dans la memoire de la carte video et evite ainsi les Offlay Buffer qui ralentissent et bouffent de la meme pour rien.
Enfin, Swing utilise Java2D qui utilise les appels directs au systeme lorsqu'il sont dispo (par exemple DirectDraw sous WinXX), pour Linux je me souvient plus si il utilise DRI ou pas ...
>c'est obligatoirement gros actuellement
Alors explique mois comment tu fait tenir ca sur un iPaq 32Mo ????? si t'as deja 10Mo de VM et 10Mo de softs et 15 appli qui tournent en permanence (c'est mon cas!!!)...
Oui, swing a eut des PB de perfs et Oui il sont corrigés !!!
Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve : (Score: 1/#0) - Lundi 24 Septembre à 18:29
Ajouté par boubou ( #97 / 137 XP )
Il faut apprendre à lire.
- "run natively" ça veut dire compilé, pas interprété. Tu peux raconter tout ce que tu veux sur le JIT, etc. il n'empêche que swing ça rame (vu le nombre couches, c'est pas étonnant). Qt est compilé... Pour le reste sur swing, on est d'accord, c'est sûrement la plus belle bibliothèque de fenêtrage actuelle. Mais bon, ça rame...
>- "There are speed and memory issues associated with Java"
Sur le fond, il a raison. Quand tu démarres une JVM, c'est obligatoirement gros actuellement (genre une dizaine de mo). Quand tu crèes un objet, ça prend plein de place mémoire (de l'ordre de 16 octets par objet vide avec le jdk 1.3 de sun sous linux), etc. Si tu codes comme en C, avec une bonne JVM, ça va presque aussi vite que du C, parfois plus vite. Par contre, dès que tu codes vraimebt objet, C++ reste meilleur sur de nombreux points, par exemple parce que l'overhead mémoire est plus faible et parce qu'on peut passer les objets par valeur, et qu'on peut inliner les méthodes.
>- swing n'est pas libre, bordel !!!!!!!!!
Swing est en comunity source, t'as tout le source code et tu peux deriver le code comme tu veux mais tu n'as pas le droit d'ecrire un librairie qui porte le meme nom ... je trouve ca plutot sympas car ca evite de se faire exploser la compatibilité binaire de ces appli pour un oui ou pour un non (ca te rappelle rien ...?!?)
Il existe de nombreux projets qui ecrivent des outils utilisant swing et qui sont en opensource : Jext/Jedit/Netbeans/ .... et cela ne semble gener personne sauf les puristes et autre guru de la GPL :o)
Et d'autre part si un Jour Sun nous prend la tete, rien n'interdit de reecrire exactemet la meme biblio (meme noms de package) et cela en GPL ou BSD ;-)
Comme le fait deja le projet ClassPath de la GNU pour toute les fondations de Java !
Donc no stress ...
Enfin concernant ton argument memoire, je sui d'accord que si tu veux optimizer a fond le C c'est mieux mais j'ajouterais l'assembleur est encore mieux ... c'est une question de choix !
Java est 40% plus productif que le C++ et c'est un FAIT que tout les DP qui on mené des projets C++ et Java pouront te confirmer !
C'est pas une paille tout de meme 40%...
Une derniere remarque sur la memoire, les JIT de 2eme generations sont capable d'inliner avec un niveau de profondeur illimité et conditionel dynamiquement (càd qu'il est déterminé à la phase d'optimization). Enfin, l'utilisation de references dans un prog strucurellement complexe produit un effet bennefique sur la memoire utilisée et sur l'ensemble des perfs globales (tri, recherche, comparaisons d'objets ....)
Maintenant si tu trouve que certains points dans java ont besoin d'amelioration, libre a toi de patcher le code source de la VM et d'envoyer tes patchs à Sun (regarde dans les sources de la VM de Sun tu y trouveras deja un certains nombres qui l'ont fait!!!) ou de demander un JSR http://www.jcp.org(...) pour demander un evolution plus majeure ...
[^] # Emmm qqe correctifs :
Posté par Anonyme . En réponse à la dépêche Interview du president TrollTech. Évalué à -2.
Qu'est ce qui rame ... donne des exemples ...
avec quoi comme VM, comme comme parametre de GC (mode incremental, clean/mark/sweep)....
Si t'as un iPAQ sous la main, met SavaJeXE et je n'aurais pas besoins de te convaincre ....
L'un des PB de Swing etait la conso memoire mais avec la 1.4 il va directement pioché dans la memoire de la carte video et evite ainsi les Offlay Buffer qui ralentissent et bouffent de la meme pour rien.
Enfin, Swing utilise Java2D qui utilise les appels directs au systeme lorsqu'il sont dispo (par exemple DirectDraw sous WinXX), pour Linux je me souvient plus si il utilise DRI ou pas ...
>c'est obligatoirement gros actuellement
Alors explique mois comment tu fait tenir ca sur un iPaq 32Mo ????? si t'as deja 10Mo de VM et 10Mo de softs et 15 appli qui tournent en permanence (c'est mon cas!!!)...
Oui, swing a eut des PB de perfs et Oui il sont corrigés !!!
Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve : (Score: 1/#0) - Lundi 24 Septembre à 18:29
Ajouté par boubou ( #97 / 137 XP )
Il faut apprendre à lire.
- "run natively" ça veut dire compilé, pas interprété. Tu peux raconter tout ce que tu veux sur le JIT, etc. il n'empêche que swing ça rame (vu le nombre couches, c'est pas étonnant). Qt est compilé... Pour le reste sur swing, on est d'accord, c'est sûrement la plus belle bibliothèque de fenêtrage actuelle. Mais bon, ça rame...
>- "There are speed and memory issues associated with Java"
Sur le fond, il a raison. Quand tu démarres une JVM, c'est obligatoirement gros actuellement (genre une dizaine de mo). Quand tu crèes un objet, ça prend plein de place mémoire (de l'ordre de 16 octets par objet vide avec le jdk 1.3 de sun sous linux), etc. Si tu codes comme en C, avec une bonne JVM, ça va presque aussi vite que du C, parfois plus vite. Par contre, dès que tu codes vraimebt objet, C++ reste meilleur sur de nombreux points, par exemple parce que l'overhead mémoire est plus faible et parce qu'on peut passer les objets par valeur, et qu'on peut inliner les méthodes.
>- swing n'est pas libre, bordel !!!!!!!!!
Swing est en comunity source, t'as tout le source code et tu peux deriver le code comme tu veux mais tu n'as pas le droit d'ecrire un librairie qui porte le meme nom ... je trouve ca plutot sympas car ca evite de se faire exploser la compatibilité binaire de ces appli pour un oui ou pour un non (ca te rappelle rien ...?!?)
Il existe de nombreux projets qui ecrivent des outils utilisant swing et qui sont en opensource : Jext/Jedit/Netbeans/ .... et cela ne semble gener personne sauf les puristes et autre guru de la GPL :o)
Et d'autre part si un Jour Sun nous prend la tete, rien n'interdit de reecrire exactemet la meme biblio (meme noms de package) et cela en GPL ou BSD ;-)
Comme le fait deja le projet ClassPath de la GNU pour toute les fondations de Java !
Donc no stress ...
Enfin concernant ton argument memoire, je sui d'accord que si tu veux optimizer a fond le C c'est mieux mais j'ajouterais l'assembleur est encore mieux ... c'est une question de choix !
Java est 40% plus productif que le C++ et c'est un FAIT que tout les DP qui on mené des projets C++ et Java pouront te confirmer !
C'est pas une paille tout de meme 40%...
Une derniere remarque sur la memoire, les JIT de 2eme generations sont capable d'inliner avec un niveau de profondeur illimité et conditionel dynamiquement (càd qu'il est déterminé à la phase d'optimization). Enfin, l'utilisation de references dans un prog strucurellement complexe produit un effet bennefique sur la memoire utilisée et sur l'ensemble des perfs globales (tri, recherche, comparaisons d'objets ....)
Maintenant si tu trouve que certains points dans java ont besoin d'amelioration, libre a toi de patcher le code source de la VM et d'envoyer tes patchs à Sun (regarde dans les sources de la VM de Sun tu y trouveras deja un certains nombres qui l'ont fait!!!) ou de demander un JSR http://www.jcp.org(...) pour demander un evolution plus majeure ...
Bye a toi et bon tux ;-)