Articles précédents : Articles
- [57] Brevets : IBM entre dans la danse ?
- [63] Retour d'expérience et documentation de création d'un réseau de terminaux X
- [21] Les utilisateurs de Mac ont enfin leur "LiveCD" linux grâce à Gentoo
- [61] Nouveautés : astuces, sondages, logo, suppression de compte
- [12] Simuler l'environnement ARM sous Linux logiciellement
- [21] La première fête parisienne des musiques Libres
- [79] Un nouveau FPS pour Linux
- [155] Pourquoi ne pas utiliser Linux
- [66] Waste, réseau p2p privé / chiffré
- [34] Cinéastes amateurs
Liens connexes
- l'article (3286 hits)
- Performance & Scalability Guide for the J2SE Platform [Sun] (905 hits)
Dépêche modérée par
Articles : Légende urbaine : un alligator dans le ramasse-miettes
Posté par jcs (page perso, ). Modéré le 05 juin 2003.
![[en]](../../../images/en.png)
l'article (3286 hits)-
Performance & Scalability Guide for the J2SE Platform [Sun] (905 hits)
> Lire les commentaires (231 commentaires, moyenne: 1,7).
[+] Re: Légende urbaine : un alligator dans le ramasse-miettes
attention chérie, ca va troller :)
Développeur OpenSource
-
[+] [^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Tutur () le 05/06/2003 à 15:46. (lien). Évalué à -5.C'est pas un troll, c'est du FUD
http://www.geocities.com/SiliconValley/Hills/9267/fuddef.html(...)--
\_°< C01N C01N ! >°_/-
[+] [^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Damien POBEL (page perso, ) le 05/06/2003 à 16:34. (lien). Évalué à -4.j'ai la syphillis mais je sais pas comment ca s'ecrit
-
Objets immuables
-
[^]Re: Objets immuables
Posté par Guillaume Rousse (page perso, ) le 05/06/2003 à 08:57. (lien). Évalué à 4.Mutable et immutable sont des termes français.
Persistant est un contre-sens par contre: ce n'est pas parce qu'un objet persiste qu'il ne change pas.-
[^]Re: Objets immuables
-
[^]Re: Objets immuables
Posté par Roger Rabbit () le 05/06/2003 à 09:09. (lien). Évalué à 8.immutable = non mutable = un fois l'objet crée, il est non modifiable. Le modifier revient à le remplacer par un objet. C'est le cas des String en java.
objet persistant = objet dont on peut enregistrer l'état et ainsi réactiver ultérieurement.-
[^]Re: Objets immuables
Posté par Benoît Bailleux (Jabber id, ) le 05/06/2003 à 11:44. (lien). Évalué à 3.Pour information :
immutable (in "Webster's Revised Unabridged Dictionary")
\Im*mu"ta*ble\, a. [L. immutabilis; pref. im- not + mutabilis mutable. See Mutable.] Not mutable; not capable or susceptible of change; unchangeable; unalterable.
Le Robert contient la définition suivante :
IMMUTABLE [i(m)mytabl] adj.
- Rare et littér. Qui ne peut changer. - Immuable (plus cour.)
Alors en se la pétant rien qu'un peu, on peu utiliser ce terme tel quel (lequel a donné l'autre : l'Anglais, ou le Français ?)--
BB-
[^]Re: Objets immuables
Posté par NebuchadnezzaR () le 05/06/2003 à 11:47. (lien). Évalué à 8.(lequel a donné l'autre : l'Anglais, ou le Français ?)
le latin ;-)
-
-
-
-
[^]Re: Objets immuables
Posté par Brice Carpentier (Jabber id, page perso, ) le 05/06/2003 à 09:00. (lien). Évalué à 1.Dis moi, tu pourrais m'expliquer le "and now, comething completly different" sur ta page ?
j'avais un prof de java qui nous mettait ca a chaque cours on a jamis compris pourquoi !
(oui, vous pouvez moinsser, mais attendez svp qu'il réponde c important)--
Développeur OpenSource-
[^]Re: Objets immuables
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 05/06/2003 à 09:03. (lien). Évalué à 6.ben parce que c'est lui, ton prof de Java ?
-
[^]Re: Objets immuables
Posté par huhuhu () le 05/06/2003 à 09:06. (lien). Évalué à 3.C'est un spectacle des monty python, non ?
-
[^]Re: Objets immuables
Posté par Brice Carpentier (Jabber id, page perso, ) le 05/06/2003 à 09:07. (lien). Évalué à 1.c'est en effet ce qu'on m'a dit mais on a jamais été capable de me dire lequel
--
Développeur OpenSource-
[^]Re: Objets immuables
Posté par fantome asthmatique () le 05/06/2003 à 09:23. (lien). Évalué à 3.c'est une transition dans le monty python flying circus, entre
les sketchs, on voyait john cleese apparaitre et déclarer :
"and now for something completly different".
cf le splash screen de la demo de wxpython par exemple :-)
-
[^]Re: Objets immuables
Posté par Hyacinthe De Cavallère () le 05/06/2003 à 09:23. (lien). Évalué à 7.<Culture Monty Python>
Ce n'est pas un spectacle des monty python, mais une phrase récurrente de l'emission 'Monty Python Flying Circus' que John Cleese, assis derrière un bureau, déclamait en dehors de tout contexte (comme d'habitude chez les Pythons).
C'est une phrase très connue outre manche (et chez les anglophones) au point qu'une publicité (je ne sais plus pour quel produit) s'en ait servi. De nombreux comiques l'utilisent également comme référence culturelle....
</Culture Monty Python>-
[^]Re: Objets immuables
Posté par CyrMon () le 05/06/2003 à 09:42. (lien). Évalué à 2.C'est effectivement une transition récurrente dnas la série des Monty Python, mais c'est également le titre original de leur premier film sorti en france sous le titre Pataquesse, qui est une compilation de leurs meilleurs sketchs retournés pour le cinéma.
Il est à noter que la véritable citation est, comme dit plus haut, "And now, for something completely different".
-
-
-
-
[^]Re: Objets immuables
Posté par LeMagicien Garcimore () le 05/06/2003 à 09:22. (lien). Évalué à 3.Parfois, entre deux sketch du Monty Python Flying Circus (LA serie des Monty Pyhton sur la BBC entre 1969 et 1974), une voix off dit : "And now for something completely different !". En effet, les sketchs des Monty Python s'enchaine sans aucun lien entre eux :)
Voilaaaaa
-
[^]Re: Objets immuables
Posté par Brice Carpentier (Jabber id, page perso, ) le 05/06/2003 à 09:31. (lien). Évalué à 0.et bien merci pour ces qqs explications attendues pendant tout un semestre :)
et maintenant moinssez moi ca ;)--
Développeur OpenSource-
[^]Re: Objets immuables
Posté par jerome (page perso, ) le 05/06/2003 à 14:05. (lien). Évalué à 2.N'oublions pas que si le langage Python s'appelle ainsi c parce que Guido Van Rossum était un fan de cette émission :)
-
[^]Re: Objets immuables
Posté par Tony Flow () le 05/06/2003 à 14:58. (lien). Évalué à 3.Et oui on doit beaucoup aux Monty Python...
N'oublions pas également que le terme SPAM vient également d'un de leur sketch !
(héhé, j'adore John Cleese dans le Ministère des Démarches Ridicules)-
[^]Re: Objets immuables
Posté par Benoît Bailleux (Jabber id, ) le 06/06/2003 à 05:54. (lien). Évalué à 1.Et attention, car personne ne s'attend à l'inquisition espagnole !
--
BB-
[^]Re: Objets immuables
Posté par Eric Boulat () le 06/06/2003 à 20:20. (lien). Évalué à 1.Et n'oublions pas l'herisson géant de Dinsdale !
-
[^]Re: Objets immuables
Posté par Jean-Marc Leroy (page perso, ) le 10/06/2003 à 13:04. (lien). Évalué à 1.et le poulet vicieux de Bristol !
-
-
-
-
-
-
perfs de java
mais non java n'est pas lourd !
on fait même des serveurs X avec !
http://www.jcraft.com/weirdx/(...)
(il supporte même la transparence, bien avant les hacks de XFree)
Malheureusement la plupart des programmes pour java sont lourds, eux :-(
-
[^]Re: perfs de java
Posté par Sami Dalouche (page perso, ) le 05/06/2003 à 09:01. (lien). Évalué à 4.et bien c pourtant simple : il faut abandonner Swing / AWT au profit des bindings GTK/GNOME pour java, abandonner la JVM au profit de GCJ ( je sais, ce n'est pas complet, mais on a toujours plus de possibilites qu'avec du c de base...), et ensuite, java c'est seulement YAPL (Yet Another Programming Language) :p
et hop, pas plus lourd que le reste, avec l'avantage en prime d'avoir un beau code ...
sam-
[^]Re: perfs de java
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 05/06/2003 à 09:09. (lien). Évalué à 6.Mais non mais non, SWING a reçu un régime dramatiquement amaigrissant depuis le JDK1.3 (avec des gains de perfs d'au moins 20%). Par contre _évidemment_ si on passe son temps à créer/supprimer des containers/objets graphiques dans tous les sens dans son application, elle sera évidemment plus lente et mal fichue.
IMHO ca dépends plus de la façon de développer l'appli.
Maintenant y'a toujours le probleme de la grosse consommation de mémoire qui contribue sur les systèmes un peu faiblots à faire couler les performances (e.g. si obligé de swapper ou si XP).
Maintenant y'a aussi un probleme de chargement initial de la JVM (hmm je sais pas trop a quoi c'est dû, ptet kil alloue par défaut une certaine quantité mémoire de base au lancement).-
[^]Re: perfs de java
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 05/06/2003 à 09:11. (lien). Évalué à 0.Ah j'allais oublier, a défaut d'alligator on peut toujours faire confiance a son chameau : OCaml Power !
-
[^]Re: perfs de java
Posté par alpage (Jabber id, page perso, ) le 05/06/2003 à 09:58. (lien). Évalué à 0.Ah non le chameau c'est Perl !
-
[^]Re: perfs de java
Posté par Guillaume DESRAT (page perso, ) le 05/06/2003 à 11:29. (lien). Évalué à 4.Erreur, c'est un dromadaire pour Perl (une seule bosse !).
--
Guillaume "Zifro" DESRAT-
[^]Re: perfs de java
Posté par Nim () le 05/06/2003 à 16:10. (lien). Évalué à 0.Pourtant on parle assez facilement du camel book en parlant du joli O'Reuilly sur Perl.
Une erreur courrement faite on dirait :).-
[^]Re: perfs de java
Posté par boubou (page perso, ) le 05/06/2003 à 16:41. (lien). Évalué à 6.Non, c'est simplement que les américains n'ont pas de mot pour dromadaire. Pour eux, un chameau et un dromadaire sont des camels. Comme lobster qui désigne à la fois le homard et la langouste...
-
[^]Re: perfs de java
Posté par Tutur () le 05/06/2003 à 17:48. (lien). Évalué à 1.Comme free designe libre et gratuit.
--
\_°< C01N C01N ! >°_/-
[^]Re: perfs de java
Posté par durandal () le 05/06/2003 à 18:08. (lien). Évalué à 3.Comme penguin désigne pingouin et manchot...
-
[^]Re: perfs de java
Posté par imr () le 05/06/2003 à 20:22. (lien). Évalué à 4.comme bush désigne un fourré et la queue d'un renard
-
[^]Re: perfs de java
Posté par Aurelien Gateau (page perso, ) le 06/06/2003 à 09:38. (lien). Évalué à 4.et un gros c**
Oups désolé, c parti tout seul
-
-
-
-
-
[^]Camelidés (fut: Re: perfs de java)
Posté par Christophe GRAND (page perso, ) le 05/06/2003 à 16:52. (lien). Évalué à 2.Pourtant on parle assez facilement du camel book en parlant du joli O'Reuilly sur Perl.
Une erreur courrement faite on dirait :).
Les clopes Camel aussi ont pour emblème un dromadaire.
Les anglophones désignent par camel n'importe quel camélidé. Le dromadaire étant le dromedary et et la chameau le bactrian camel.
-
-
-
-
-
[+] [^]Re: perfs de java
Posté par Sami Dalouche (page perso, ) le 05/06/2003 à 10:58. (lien). Évalué à -1.menfin bon, de ttes facons swing c moche, et meme avec le theme gtk ki va bientot etre ajoute, ca reste pas integre a mon bureau favori :)
alors vive les applis java/gnome en gcj, qu'on puisse un peu oublier le c....
(a quand le kernel linux en java gcj ? lol)
sam
-
[^]Re: perfs de java
Posté par Nicolas ANTONIAZZI (page perso, ) le 05/06/2003 à 12:10. (lien). Évalué à 2.D'ailleurs moi il y a quelque chose qui m'ennuie un peu avec les JVM... C'est leurs optimisation douteuse sous linux.
Je ne sais pas si vous avez testé la plateforme de développement eclipse, mais sa vitesse n'a compètement rien à voir entre windows et linux. Je n'irai pas jusqu'à dire que sous windows ça tourne à fond, mais au minimum 2 fois plus vite que sous linux. En tout cas pour la réactivité d'affichage des fenetres, y'a pas photos.
Je ne sais pas trop qu'elle en est la cause (peut-être XFree)... Mais je trouve ca un peu dommage.
Enfin, de toute manière ça ne m'empeche pas de l'utiliser sous linux même si ca ramouille un peu parce que c'est tout de même bien pratique :)-
[^]Re: perfs de java
Posté par Antoine Reilles (Jabber id, page perso, ) le 05/06/2003 à 12:37. (lien). Évalué à 4.je ne crois pas que ça vienne uniquement d'xfree !
j'avais posté un journal a ce sujet, mais il semble que pour la jvm de sun, ils aient fait un gros effort sur la version windows, avec un garbage collector performant, et une bonne répartition de charge. Sur un bi-pro, avec une appli multithreadée, les deux procs sont utilisés a fond, et si l'appli ne l'est pas, les deux procs sont bien utilisés aussi, par la jvm, alors que sous linux c'est catastrophique
est ce que c'est volontaire ? probablement !
d'un autre coté, la jvm de blackdown a l'air plus optimisée que les autres, alors a quand une jvm totalement libre ? ça aiderai sûrement, non ?-
[^]Re: perfs de java
Posté par Nicolas ANTONIAZZI (page perso, ) le 05/06/2003 à 12:54. (lien). Évalué à 5.J'ai trouvé ça dans une des sections explicatives des améliorations pour la version 3 d'eclipse : http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0(...)
Proposed Items (Eclipse Platform subproject, Responsive UI theme)
The following work items are being actively investigated, but we are not yet able to promise any solution for this release:
( new) Address platform-specific UI performance problems. There is a noticable UI performance and responsiveness difference between Eclipse running on Windows and Eclipse running on Linux GTK, Linux Motif, or QNX Photon, all on the same hardware, with Windows clearly outperforming the others. Improvements made to SWT alone have not reduced this "performance gap" enough. In order to improve Eclipse performance in the other operating environments, we need to make a concerted effort to determine the root causes (suspects include low-level thread scheduling and synchronization), and then take steps to address them. [SWT, Platform UI] [Theme: Responsive UI]-
[^]Re: perfs de java
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 05/06/2003 à 13:38. (lien). Évalué à 1.Je me demande ce que donneraient les résultats avec un kernel 2.6 et une jvm tunée pour ce kernel (qui a des améliorations au niveau scheduler/threads).
-
-
-
[^]Re: perfs de java
Posté par Roger Rabbit () le 05/06/2003 à 13:57. (lien). Évalué à 1.mmmh, bien déja windows est beaucoup plus réactif que XFree au niveau
des fenetres. c'est flagrant ...
Un début d'explication a été donné sur le site www.javagaming.org ... le mec en question dirigait la team Swing/Java2D chez sun, et son explication
au problème était que la conception d'XFree rendait très délicate l'implémentation de composants GUI speed. [ je n'ai pas retrouvé ce passage, le site a été updaté il y a un an et le forum a été perdu , dsl ].
Peut etre que les raisons avancées ne sont que les prémices d'un beau
troll dans le but de masquer leur incompétence, mais c'est néanmoins la seule explication qu'il a donné .
L'équipe de sun a fait aussi beaucoup d'efforts sur les libs relatives au développement de jeux vidéos [ xbuffering, page swapping, stockage des données en ram video, vrai fullscreen .... etc ] , et malheureusement à ma connaissance ces fonctionnalités ne sont disponibles que sous plateforme win.
A l'heure actuelle je ne vois que l'association gcj/swt pour construire des gui speed ... c'est bien dommage :'((-
[^]Re: perfs de java
Posté par Roger Rabbit () le 05/06/2003 à 14:13. (lien). Évalué à 2.Java Technology on Linux
October 15, 2002
Guest Speakers: Calvin Austin, Hui Huang, and Juergen Kreileder
Moderator: Edward Ort (MDR-EdO)
http://developer.java.sun.com/developer/community/chat/JavaLive/200(...)
extrait :
" The biggest issue with Linux is the number of threads and the thread overhead."
-
[^]Re: perfs de java
Posté par Gniarf () le 05/06/2003 à 20:32. (lien). Évalué à 0.je crois qu'à ce niveau, c'est X le problème.
(et non, ce n'est pas un troll)--
Windows has no users. It has hostages.-
[^]Re: perfs de java
Posté par Trick () le 06/06/2003 à 07:53. (lien). Évalué à 1.Il n'existe pas une distribution linux dont le l'affichage et le bureau serait fait en java? (ma mémoire me jouerait-elle des tours?)
Sinon est-ce que ce ne serait pas un remède à la lenteur du X et de libérer aussi la mémoire X pour la machine virtuelle Java qui en bouffe pas mal?
-
-
-
[^]Re: perfs de java
Posté par marvin () le 05/06/2003 à 16:03. (lien). Évalué à 1.>D'ailleurs moi il y a quelque chose qui m'ennuie un peu avec les JVM... C'est leurs optimisation douteuse sous linux.
Yep. On remarquera également l'absence sous linux d'une version officielle de l'API Java de communication (javax.com), permettant entre autres l'accès à un port série/parallèle. Il existe bien une alternative (la classe "gnu.io.RXTXCommDriver", par Kevin Hester) mais celle-ci prend en compte uniquement les ports séries...-
[^]Re: perfs de java
Posté par Laurent Vaills (page perso, ) le 06/06/2003 à 06:16. (lien). Évalué à 2.L'implémentation libre de javax.comm qui est donc RXTX marche très bien avec les ports parallèles aussi.
De plus cette implémentation n'est pas seulement disponible que sous Linux mais aussi sous Windows, SparcSolaris et MacOs me semble-t-il.
http://www.rxtx.org(...)-
[^]Re: perfs de java
Posté par marvin () le 06/06/2003 à 14:25. (lien). Évalué à 1.>L'implémentation libre de javax.comm qui est donc RXTX marche très bien avec les ports parallèles aussi.
Ooops, effectivement, je m'était basé sur le site de Kevin
(http://www.geeksville.com/~kevinh/linuxcomm.html(...)):
>There is no parallel port support. If you'd like to add this support, please join the RXTX development effort.
L'information date un peu, apparement :)
-
-
-
[^]Re: perfs de java
Posté par boubou (page perso, ) le 05/06/2003 à 18:00. (lien). Évalué à 2.Oui, la partie graphique est en général plus lente sous linux, mais bon, pour le reste, ce n'est pas si clair. Voir par exemple le volanomark (http://www.volano.com/report/index.html(...)) ou linux se défend bien. La conclusion du dernier test de volano est d'ailleurs un must...
-
-
-
[^]Re: perfs de java
Posté par Roger Rabbit () le 05/06/2003 à 09:12. (lien). Évalué à 2.Les versions 1.4.2 et 1.5 du jdk de Sun permettent l'utilisation de GTK . Sinon il reste SWTd'eclipse qui permet aussi de générer des interfaces GTK ( qt est à l'étude ).
-
[^]GTK...
Posté par Francois Revol (page perso, ) le 05/06/2003 à 09:21. (lien). Évalué à 1.oué, mais alors bonjour la portabilité... GTK c pas dispo partout (quoique java non plus en fait). Autant utiliser la BeAPI tant qu'on y est (en fait elle a vraiment quelque chose de java dedans, je sais pas pkoi).
-
[^]Re: GTK...
Posté par Roger Rabbit () le 05/06/2003 à 09:25. (lien). Évalué à 1.sous w$ ca utilise les composants w$ ...
-
-
[^]Re: perfs de java
Posté par Pat Le Nain (Jabber id, page perso, ) le 05/06/2003 à 09:48. (lien). Évalué à 1.Pour le 1.4.2, c juste une émulation des widgets GTK (et pas des widgets GTK natifs)
--
Demat le bouchot !-
[^]Re: perfs de java
Posté par Roger Rabbit () le 05/06/2003 à 09:58. (lien). Évalué à 5.oui ce sont des L&F pour le 1.4.2 , dsl ne pas avoir précisé. Mais du "vrai" gtk pour swt ...
plus d'info là :
Sur les nouveautés Swing
http://java.sun.com/j2se/1.4.2/docs/guide/swing/1.4/Post1.4.html#1.(...)
Sur le 1.4.2
http://developer.java.sun.com/developer/community/chat/JavaLive/200(...)
Sur SWT
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-ho(...)
-
-
[^]Re: perfs de java
Posté par Thomas Cataldo (page perso, ) le 06/06/2003 à 00:40. (lien). Évalué à 2.C'est pas du gtk, c'est toujours du dessin avec des méthodes paint fait pour ressembler au theme gtk. Donc ça rame toujour autant. SWT par contre utilise bien le toolkit natif de la plateforme (gtk, mfc ou motif suivant l'os).
-
[^]Re: perfs de java
-
-
-
[^]Re: perfs de java
-
[^]Re: perfs de java
Posté par boubou (page perso, ) le 05/06/2003 à 16:44. (lien). Évalué à 1.abandonner la JVM au profit de GCJ
Bof. Rien ne prouve qu'un code compilé en natif soit plus efficace qu'un code compilé en JIT (tu me diras qu'on pourrait avoir du JIT dans GCJ (on est d'ailleurs obligé pour faire du vrai Java), mais bon, ça devient n'importe quoi). En "regardant" un code java tourner, on peut faire des optimisations très sioux qui ne peuvent pas être faites statiquement...-
[^]Re: perfs de java
Posté par Christophe GRAND (page perso, ) le 05/06/2003 à 17:27. (lien). Évalué à 1.Rien ne prouve qu'un code compilé en natif soit plus efficace qu'un code compilé en JIT
Une fois "jitté" certes ! Mais il faut bien que le compilo JIT fasse son boulot alors qu'avec un compilo classique c'est déjà fait.
Le régime permanent est similaire dans les deux cas mais l'une des deux solutions crée un régime transitoire beaucoup plus important ce qui se traduit par un manque de réactivité.
Moralité :
Si tu as une appli qui ne s'arrête jamais le code compilé en natif n'est pas plus efficace qu'un code compilé en JIT.
Si tu as une appli utilitaire que tu n'arrêtes pas de lancer et d'arrêter, là le code natif est meilleur.-
[^]Re: perfs de java
Posté par boubou (page perso, ) le 05/06/2003 à 17:37. (lien). Évalué à 2.Nous nous sommes mal compris. Le code natif obtenu par le JIT peut être meilleur qu'un code compilé statiquement, par exemple en inlinant certaines méthodes alors qu'a priori (en analyse statique) on pouvait croire que ça ne valait pas le coup, en supprimant au vol certains tests (sur les bornes d'un tableau par exemple), etc. Les analyses statiques sur un code sont très coûteuses et beaucoup de compilateurs ne peuvent pas se permettre de les faire. Quand tu interpètes du code, faire une analyse en même temps ne coûte pas énormément plus, ce qui permet de faire des choses difficiles à envisager en statique.
-
[^]Re: perfs de java
Posté par boubou (page perso, ) le 05/06/2003 à 17:39. (lien). Évalué à 2.Oups, j'ai oublié la moitié de ma réponse. Quand tu compiles ATLAS, la meilleure bibliothèque de calcul matriciel actuelle, ça prend en gros 2 heures (même sur une machine très récente), parce que le code est optimisé avec des techniques typiques des JIT (chronométrages de boucles, tests sur l'empreinte mémoire, etc.). Or, ATLAS ne fait rien, en terme de fonctionnalités : ça se limite à des produits de matrices. Imagines le temps de compilation pour une grosse appli.
-
[^]Re: perfs de java
Posté par Jerome Herman () le 05/06/2003 à 17:44. (lien). Évalué à 3.un régime transitoire beaucoup plus important ce qui se traduit par un manque de réactivité.
A condition bien sur que le passage par le regime transitoire ne permette pas de recuperer le temps perdu.
Il n'est pas rare du tout que le retour sur investissement en JIT se fasse des le deuxieme passage dans une zone de tests. Un compilateur JIT est capable de determiner si la realisation d'un test est susceptible de changer ou pas, et si il y a des portions du tests qui seront toujours fausses. De la il peut parfaitement optimiser le compile.
Au premier passage on aura Evaluation de la zone de test+compilation+evaluation optimisee du resultat, des le deuxieme on aura directement evaluation optimisee du resultat. Un language pur compile est incapable de faire ca. Sur des tests "lourds" l'overhead de java est negligeable au premier passage, et le gain au deuxieme est souvent monstrueux.
Moralite :
Si il y a des portions de ton programme qui servent plus d'une fois lors d'une utilisation standard, le JIT peut reserver des surprises.
Kha
-
-
-
[^]Re: perfs de java
Posté par HappyCrow () le 09/06/2003 à 08:31. (lien). Évalué à 0.Seulement YAPL...
oui mais c'est interprete donc c'est forcement plus lent que ce qui est compile...
Pour des langages interpretables et compilables et independant de l'OS (toutes les librairies Java ne sont pas compilables!):
Le langage OCaml (francais)
http://caml.inria.fr(...)
Le langage Scheme (americain)
http://www.swiss.ai.mit.edu/projects/scheme/index.html(...)
Pour etre sur une bonne fois pour toute que "JAVA EST BIEN UNE USINE A GAZ"
(le lien qui suit est un comparatif de la plupart des langages)
http://www.bagley.org/~doug/shootout/(...)
Java se fait ramasser dans la plupart des tests...par OCaml par exemple.
Mon avis perso: Java ce n'est bien qu'une mode et seule la puissance commerciale
de SUN en est la cause...
-
Re: Légende urbaine : un alligator dans le ramasse-miettes
J'ai le rêve doux qu'un jour, les gens comprendront que Java en soi n'est pas lent. Malheureusement, c'est assez difficile de faire comprendre aux gens, même avec des benchs, que Java est aussi rapide qu'un autre langage. Pourquoi ?
Parce que la plupart du temps, les programmes sont codés avec des méthodes assez sales, inspirées des fameux "débuter Java en 21 jours" et autres âneries qui proposent l'utilisation des classes anonymes, internes et autres stupidités qui ont pour but unique de créer un maximum d'objets, alors que ça n'a aucun sens.
Malheureusement, pour qu'un développeur comprenne ça, il lui faut beaucoup de temps, et beaucoup de codes qui sont déja utilisés sont faits alors que le développeur ne le sait pas. Du coup, tout le monde croit que Java est lent, lourd, et tout ce qu'on veut.
Mais pourtant, Java est utilisé dans les nouvelles générations de portables, qui ne sont pas des foudres de guerre. Pourquoi ?
Parce que Java est sûr, facile à développer, et dispose de performances largement au niveau des autres langages.
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Roger Rabbit () le 05/06/2003 à 09:41. (lien). Évalué à 1.Tout a fait d'accord avec toi sur l'ignorance des gens à propos de java. Maitriser java [ le langage, l'utilisation de l'api, l'implémentation de l'api, la vm , le gc , les modèles de conception ... ] est un processus tres long...
Je voulais juste préciser que l'utilisation en soi de classes anonymes ou internes n'est pas une stupidité ... c'est leur mauvaise utilisation - ie la gestion de la création d'objet - qui peut poser problème.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Moby-Dik () le 05/06/2003 à 10:45. (lien). Évalué à 1.Maitriser java [ le langage, l'utilisation de l'api, l'implémentation de l'api, la vm , le gc , les modèles de conception ... ] est un processus tres long...
C'est le principal problème de Java. Maîtriser Perl ou PHP, ça prend trois jours (allez, une semaine pour Perl). Java est le pain-bénit des charlatans qui vendent de l'"expertise" et du "consulting" à tout va à de pauvres gens dupés par la propagande des magazines informatiques.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Yusei () le 05/06/2003 à 10:50. (lien). Évalué à 5.Oh ? Moi j'aime beaucoup Perl, mais alors je suis très très loin de le maîtriser, même après plus d'une semaine...
Disons que je le maîtrise assez pour pouvoir écrire mes programmes, mais pas assez pour pouvoir comprendre à coup sûr ce que fait le programme de quelqu'un d'autre... Les joies du "Il y a plusieurs manières de le faire" :-)
-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Roger Rabbit () le 05/06/2003 à 11:00. (lien). Évalué à 5.comme partout il faut du temps pour connaitre un langage et ses spécificités. Idem pour l'utilisation des libs. Pour java on peut noter qu'il
n'y a qu'une api majeure qui réalise bon nombre de choses. C'est selon
moi un gros [+]. Pas besoin de se prendre la tete à comparer les Xmilles libs dispos qui font la meme chose, plus ou moins différement.
Tu dis que maitriser PHP prend 3 jour, maitriser perl prendrait 1 semaine. Bon la c'est net tu n'es pas sérieux :) Tous les gens qui font du php on fait au minimum 3 jour de php ... pourtant tout le monde n'est pas un php
guru ... et a regarder de plus pres du code php on observe qu'il a ceux qui
savent [ bien ] coder du php et les autres ... idem pour perl .... ne connaissant que peu perl et si j'avais a en faire, l'expertise d'un guru perl me semblerait la bienvenue.-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Moby-Dik () le 05/06/2003 à 11:46. (lien). Évalué à 0.Est-ce qu'on peut parler français ? Pour moi un gourou ("guru") c'est un type qui lance des incantations ;)
Sérieusement. Je n'ai pas parlé de devenir un "gourou", mais d'être capable de programmer correctement. PHP est à peu près le langage le plus beginner-friendly à l'heure actuelle ; Java est à l'opposé. Trouve-moi un doc aussi concis, simple, accessible que le manuel officiel PHP pour se mettre le pied à l'étrier en Java. Pour programmer correctement, tu n'as pas besoin de connaître l'API par coeur ; il suffit de connaître le langage et de s'être familiarisé avec la structure de l'API (à condition d'avoir une doc correcte à disposition, ce qui est le cas pour PHP).
Pas besoin de se prendre la tete à comparer les Xmilles libs dispos qui font la meme chose
Je n'ai pas parlé des XWindowseries, j'ai parlé de PHP et Perl. Les principaux modules de PHP sont livrés dans la distribution standard. Pour Perl, il y a CPAN. Je ne connais pas Python mais j'imagine qu'il y a ce genre de choses aussi.
Quant à Java, l'API est centralisée mais elle est mammouthesque.
et a regarder de plus pres du code php on observe qu'il a ceux qui
savent [ bien ] coder du php et les autres
Qu'est-ce que tu essaies de démontrer ? Ce n'est pas parce qu'un langage est plus facile qu'un autre qu'il n'y a pas de mauvais programmeurs. Ce n'est pas parce qu'on arrive pas à lire un programmer Perl mal foutu qu'on n'est pas capable de programmer correctement en Perl.-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par shbrol () le 05/06/2003 à 12:06. (lien). Évalué à 1.et en francais, "beginner-friendly", ca donne quoi ?
-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Mickaël Rémond (page perso, ) le 05/06/2003 à 12:18. (lien). Évalué à 1.C'est l'«ami des débutants» ;-)
-
-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par vrm (page perso, ) le 05/06/2003 à 12:22. (lien). Évalué à 4.pas begginer friendly, goret friendly
90% du code php c'est programmé rapide et mal (voir le support objet de php..)-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Amand Tihon (page perso, ) le 05/06/2003 à 13:54. (lien). Évalué à 7.Entièrement d'accord avec toi.
Ce langage qui semble si attrayant quand on le découvre alors qu'on sort du C/C++ se montre vite assez ignoble.
Tu parles du support objet bancal, mais il y a aussi les inconsistances dans le nommage des fonctions... même au sein d'une seule "lib" ( http://www.php.net/manual/en/ref.strings.php(...) ), certaines fonctions agglutinent, d'autres utilisent le _ pour séparer les mots : stripslashes() vs. strip_tags() par exemple.
Sans oublier que « c'est tellement facile » qu'on se retrouve avec un source où structure HTML et instructions php se mélangent allègrement...
Vous l'aurez compris, je n'aime plus ce langage :)-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par _seb_ () le 05/06/2003 à 14:35. (lien). Évalué à 7.Je suis d'accord avec toi que PHP manque un peu de structure (nom des fonctions, codage en pseudo-objet, etc.) mais cela devrait être remis à plat lors de la nouvelle version (PHP 5).
Rappellons également que PHP est un language très jeune, 7/8 ans pas beaucoup plus AMHA.
Ses performances, ses "libertés" de programmation (tu peux faire des choses très vite fait et mal codées mais qui fonctionnent ou faire du code très propre) sont des atouts très interressants pour des developpements (web) qui évoluent en permanance. PHP est bien fait pour ce genre de chose. Le p'tit stagiaire va pouvoir faire sa page web sans trop de problème et rapidement être motivé pour faire la suite.
Java, c'est un gros bouzin dont les fonctionnalités sont énormes (et interréssantes) mais qui necessite une expertise pointue (de l'experience et des connaissances). Les projets qui utilisent java pour faire du java, on en voit trop souvent et on voit bien dans le code qu'ils ne profitent en rien des suptilités du language (objet qui ressemble à une grosse bibliothèque de methodes).
Java, pourquoi pas ? ou plutôt Java ! Pourquoi ?-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par xsnipe () le 05/06/2003 à 14:47. (lien). Évalué à 1.On peut aussi coder proprement avec PEAR non?? Mais bon en dehors des templates, c'est vrai que le php de base n'est pas très structuré mais pas bcp plus que le jsp tt de même...
La version 5 est très alléchante.--
Debian ... gentoo moi ça et vite :)
-
-
[+] [^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Moby-Dik () le 05/06/2003 à 18:04. (lien). Évalué à -4.« c'est tellement facile » qu'on se retrouve avec un source où structure HTML et instructions php se mélangent allègrement...
C'est marrant tous les gens qui sont allergiques au mélange code/HTML. C'est pourtant un des avantages d'un langage comme PHP. Note : personne ne t'oblige à mélanger code et HTML ; mais tu en as la possibilité et c'est très bien comme ça (sauf pour les intégristes fatigants de la programmation élitiste qui voudraient bien forcer les autres à ne programmer que d'une manière standardisée).
Et si le programmeur est mauvais ou paresseux, ce n'est pas le langage qu'il faut remplacer.
-
-
[+] [^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Moby-Dik () le 05/06/2003 à 17:53. (lien). Évalué à -2.J'adore ce genre d'arguments. Personnellement les rares fois où j'ai dû débugger du code Java c'était écrit avec les pieds (et bonjour le casse-tête quand la conception objet est foireuse : du genre confusion encapsulation / héritage). Comme quoi, les anecdotes, on peut leur faire dire ce qu'on veut, et n'importe quel langage aux mains d'un programmeur peu soigneux peut devenir une horreur (mais Java a l'avantage de la constance sur ce point :-)).
voir le support objet de php.
Ca ne gêne que ceux qui ne jurent que par l'objet et ne comprennent pas le bénéfice de la simplicité. PHP a au moins l'intérêt de proposer de l'objet en plus du procédural, alors que Java ne connaît pas le procédural, ce qui oblige à faire de la conception lourde pour la moindre petite appli. Remarque, c'est bien, ça gonfle le prix des prestations, ce qui rejoint mon propos du départ.-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Gloo () le 05/06/2003 à 21:18. (lien). Évalué à 3."Ca ne gêne que ceux qui ne jurent que par l'objet et ne comprennent pas le bénéfice de la simplicité."
J'ai vu du C plus agreable que du java. L'inverse aussi. Depend des codeurs et du lecteur, pas du langage. L'objet est supposé se rapprocher de la façon dont l'Homme apprehende les choses.
"Java ne connaît pas le procédural"
J'ai vu des methodes de 300 lignes en java... je crois que l'on est loin de l'objet avec son identité, son comportement et son état... ou d'une conception compliquée: y en a pas.
"ce qui oblige à faire de la conception lourde pour la moindre petite appli"
cf plus haut.
"ce qui rejoint mon propos du départ."
L'histoire des charlatans ? C'est pareil dans tous les secteurs, pour toutes les technos.
"les intégristes fatigants de la programmation élitiste qui voudraient bien forcer les autres à ne programmer que d'une manière standardisée"
Ou qui voudraient simplement faire passer des moulinettes dans le code ? Qui voudraient que les gens puissent se comprendre et travailler efficacement ensemble ?
Il y a de vrais integristes fatiguants quelle que soit la techno.
"Ca ne gêne que ceux qui ne jurent que par l'objet et ne comprennent pas le bénéfice de la simplicité"
Ceux qui ne comprennent rien à l'objet, pensent que c'est plus compliqué que du procedural.
Enfin bon, je te sens aigri avec Java. Perso, je m'en fiche. C'est un langage comme un autre et je pensais que ca allait troller plus sur l'article qui a lui seul vaut dejà 150 commentaires, mais qui auraient été probablement plus interessant que ton troll de petit joueur.
Bref, je te rejoins que sur un seul truc. Java, c'est proprio.-
[^]Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Tennis Prono (page perso, ) le 06/06/2003 à 09:13. (lien). Évalué à 0.J'ai vu du C plus agreable que du java. L'inverse aussi. Depend des codeurs et du lecteur, pas du langage
En poussant un peu plus loin, tu vas me dire que tu peux faire quelque chose de lisible avec du brainfuck, puisque ça dépend du codeur et du lecteur:
http://www.muppetlabs.com/~breadbox/bf/(...)--
Pas de bureau 3d libre sans drivers libres!
-
-
-
-
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par boubou (page perso, ) le 05/06/2003 à 16:48. (lien). Évalué à 1.allez, une semaine pour Perl
Quel humour ! Tu maîtrises les regexp Perl en une semaine ? Tu maîtrises la sémantique délirante de Perl en une semaine ? Tu peux relire un programme évolué en Perl en une semaine ? Quel pipo lamentable.-
[+] [^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Moby-Dik () le 05/06/2003 à 18:10. (lien). Évalué à -1.Quel pipo lamentable
Je te donne un mois pour Perl si ça te chante ;-) Ca ne change rien au fait que c'est dix fois moins que pour Java.
(quand même, pour répondre : les regexps, ça existe en-dehors de Perl, même si celles de Perl ont plus de fonctionnalités ; la "sémantique délirante", je vois pas, toutes les structures classiques sont très compréhensibles, les machins exotiques étant superflus pour l'écriture d'un programme normal ; "relire un programme évolué", oui, s'il est bien écrit, et je dirais même plus qu'en Java : ce n'est pas ma faute si certains programmeurs Perl sont des amateurs d'obfuscation, et ça ne change rien à l'utilisabilité du langage en lui-même)-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par tcws () le 06/06/2003 à 03:01. (lien). Évalué à 1.entièrement d'accord, Perl est beaucoup plus simple à utiliser que java, la "learning curve" est beaucoup plus rapide, même si on n'est pas un kador de Perl en un mois ou une semaine, on peut faire des choses fonctionnelles très rapidement, et la sémantique n'est pas délirante, elle est juste très pratique une fois qu'on a capté mais surtout, on peut si on veut l'écrire complètement classiquement tellement que ça ressemble à du javascript (mais c'est dommage de se passer de l'utilisation implicite de $_ par exemple).
Perl c'est vraiment bien :)
-
-
-
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par LeMagicien Garcimore () le 05/06/2003 à 09:48. (lien). Évalué à 3.je suis pas convaincu que les classes internes et anonymes soient responsables de pertes de performances. En effet, une classe interne est compilé dans un fichier ClasseMere$ClasseInterne.class et une classe anonyme dans ClasseMere$1.class
Ce sont des classes commes les autres une fois compilées.
Je vois pas pourquoi elle pourraient ralentir le programme...-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Yusei () le 05/06/2003 à 10:07. (lien). Évalué à 3.C'est plus une pratique de programmation qui encourage à multiplier les classes. Le chargement de classes et la créations d'objet est un processus plus long qu'un appel de méthode (surtout si la méthode peut être "inlinée"), donc au final, ça alourdit le programme. Mais je ne sais pas si c'est vraiment si sensible que ça.
Personnellement je n'aime pas le langage Java (et pourtant je m'en suis assez bouffé pour programme relativement proprement... enfin autant que possible, en Java), donc que les implémentations soient rapides ou pas, c'est la même chose.
Pour le type de programmes que je fais, par exemple, Ruby est bien plus rapide, alors que c'est un langage (interprété) réputé lent. Pour ce que je fais, il est plus rapide en temps de développement, et (au feeling) plus rapide à l'exécution... Mais je ne fais pas des calculs scientifiques avec, par exemple, je ne prétend pas être un benchmark vivant :-)-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par boubou (page perso, ) le 05/06/2003 à 17:01. (lien). Évalué à 2.surtout si la méthode peut être "inlinée"
Oui, enfin, les classes anonymes et internes, c'est fait pour implémenter des pointeurs sur fonction objets, alors dans ce genre de cas, l'inlining est par définition impossible. Donc ça ne change rien. D'autre part, je ne suis pas sûr du tout que le chargement des classes prennent vraiment du temps en Java et de toute manière, c'est négligeable sur un programme qui tourne plus de quelques secondes.
Ceci étant, si le sens de ton post est de dire qu'il manque des pointeurs sur fonction en Java, c'est un point de vue qui se défend, mais un tel ajout demanderait la modification de la JVM, alors bon...-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Yusei () le 05/06/2003 à 21:35. (lien). Évalué à 1.«Ceci étant, si le sens de ton post est de dire qu'il manque des pointeurs sur fonction en Java»
Non, je ne trouve pas que ça manque. D'ailleurs je ne faisais qu'expliquer ce que voulait dire le monsieur plus haut, en précisant que moi même je doutais que ça soit réellement sensible niveau performances.
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (page perso, ) le 06/06/2003 à 06:37. (lien). Évalué à 1.Il y a d'autres métthodes que ces horreurs pour implémenter ces pointeurs sur fonctions, mais le débat n'est pas là. Ce n'est pas seulement le chargement de classes qui est long,c 'est aussi le fait qu'à chaque appel de la méthode définissant la classe, on crée une nouvelle instance. Et ça, c'est long.
Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)
Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par boubou (page perso, ) le 08/06/2003 à 09:13. (lien). Évalué à 2.J'ai la désagréable sensation que tu ne comprends pas trop de quoi tu parles.
Ce n'est pas seulement le chargement de classes qui est long,c 'est aussi le fait qu'à chaque appel de la méthode définissant la classe, on crée une nouvelle instance. Et ça, c'est long.
Je ne vois pas en quoi les classes anonymes changent quelque chose à ça. Pour programmer une classe anonyme, il faut se baser sur une interface. Si tu n'implémentait cette interface par une classe anonyme, tu le ferais par une classe normale et tu aurais exactement le même nombre de chargement de classe et de création d'instance, sauf si tu programmes comme un porc, ce qui n'a rien à voir avec les classes anonymes.
Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)
Oui, donc tu n'as rien compris. Parce que pour faire une classe anonyme, il faut une interface...
Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.
Les pointeurs sur fonction obtenus grâce aux classes anonymes sont typés statiquement, ce qui n'est pas le cas des appels par l'objet Method. De plus, celui-ci nécesite aussi un création d'objet et, étant basé sur l'api de réflexion, il rame. Bref, tu racontes vraiment n'importe quoi.
-
-
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (page perso, ) le 05/06/2003 à 15:26. (lien). Évalué à 1.Elles le sont, par le simple fait que, à chaque passage dans la méthode qui crée l'instance, on recrée une nouvelle instance de cette classe alors qu'on aurait en général très bien pu utiliser l'ancienne instance. Ca, c'est pour les classes anonymes.
Pour les classes internes, écris-en une sous Eclipse qui accède aux données de la classe encapsulante et regarde le message d'erreur.
En clair, il dit qu'il doit créer une méthode accesseur, et passer de fait la visibilité de private à protected, juste pour ta pauvre classe interne. Tu aurais très bien pu coder toi-même une seconde classe, non interne, dans le fichier, qui fasse la même chose. Tu aurais alors nettement gagné en propreté des accès, et en évolutivité, puisque tu peux alors beaucoup plus facilement séparer tes deux classes.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Pat Le Nain (Jabber id, page perso, ) le 05/06/2003 à 15:35. (lien). Évalué à 1.Je signale juste que les erreurs et warnings à la compil sont réglables (prefs/java/compiler). Pour mes classes internes, je n'ai pas de problèmes, j'accède aux variables de la classe principale depuis les classes internes sans soucis.
--
Demat le bouchot !-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Pat Le Nain (Jabber id, page perso, ) le 05/06/2003 à 15:51. (lien). Évalué à 1.Je parlais d'Eclipse bien sûr, mais vous aurez rectifié de vous-même.
--
Demat le bouchot !
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par boubou (page perso, ) le 05/06/2003 à 16:58. (lien). Évalué à 2.Oui, enfin, quand tu utilises une classe anonyme pour implémenter un listener, tu ne crèe qu'une seule instance, donc je ne vois pas où ça rame.
Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.-
[+] [^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (page perso, ) le 06/06/2003 à 06:40. (lien). Évalué à -1.Oui, enfin, quand tu utilises une classe anonyme pour implémenter un listener, tu ne crèe qu'une seule instance, donc je ne vois pas où ça rame.
On parle bien de la même classe anonyme, là ?
Celle que tu définis avec un
addListener(new WindowListener() {
public void windowClosed() {
// je ne fais rien
}
// etc, ad nauseam
});
Celui-là, ?
Et bien dans ce cas, à chaque appel de la méthode où tu as ce code, tu crées une nouvelle instance de ta classe, par définition. Et donc, tu ralentis ton code.
Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.
Non, je décris le message d'information que peut te renvoyer Eclipse, avec une compilation un peu stricte, lors de l'utilisation de telles classes. Tout simplement parce que la création de l'accesseur synthétique est la seule méthode pour accéder à ces champs private.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Guillaume Laurent (page perso, ) le 06/06/2003 à 11:55. (lien). Évalué à 3.Et bien dans ce cas, à chaque appel de la méthode où tu as ce code, tu crées une nouvelle instance de ta classe, par définition. Et donc, tu ralentis ton code.
Et ça t'arrive souvent de faire des "addListeners()" en boucle toi ? Bien sur que ça crée une instance de la classe, il faut bien qu'il y en ait une. Ou est le problème ?-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (page perso, ) le 06/06/2003 à 13:23. (lien). Évalué à 0.Et ça t'arrive souvent de faire des "addListeners()" en boucle toi ? Bien sur que ça crée une instance de la classe, il faut bien qu'il y en ait une. Ou est le problème ?
Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
En gros, oui, ça arrive, et plus souvent qu'on ne croit.
Et pour parler d'autre chose que des listeners, on le fait souvent aussi lorsqu'on crée un FileFilter dans une méthode, et que cette méthode charge un ensemble de fichiers plusieurs fois dans l'application.
Enfin bref, il y a tout un tas de contextes où ça peut arriver, et surtout où ça risque d'arriver plusieurs fois dans la vie de l'application. Et si c'est à chaque fois qu'un bouton est affiché dans l'interface, ça peut monter très haut, et générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, et permet en outre de gérer ce pattern singleton.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Guillaume Laurent (page perso, ) le 06/06/2003 à 15:03. (lien). Évalué à 2.En gros, oui, ça arrive, et plus souvent qu'on ne croit.
Je ne vois pas comment ça peut causer un pb de perfs. Pour chaque listener il y a un objet derrière (disons un bouton), donc bien avant que la création des listeners eux-mêmes puisse poser un pb, la création de ces objets va en poser un bien plus immédiat.
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Pierre Tramo (page perso, ) le 08/06/2003 à 02:08. (lien). Évalué à 1.Ca arrive lorsque, par exemple, les boutons ne sont pas recyclés, ou le code est généré, ou le développeur n'est pas très malin.
C'est problème de développeur, pas de langage.
Dans tous les langages on peut commettre de telles horreurs sous-optimisées.
générer énormément d'instances, alors que l'utilisation d'un Listener codé dans une classe séparée est plus propre, ...
Tu peux générer autant d'instances si ta classe est séparée que si c'est une classe interne (anonyme ou non). Ce sont deux notions parfaitement orthogonales.
Et moi ça ne me parrait pas nécessairement plus propre de créer un fichier juste pour y mettre une classe d'une seule méthode dont le corps fait trois lignes à tout casser.
Dans le cas où le code de la classe interne doit accéder aux attributs ou aux méthodes de la classe externe (ce qui est fréquent pour un event listener), il faudrait fournir une instance de l'ex-objet externe à l'ex-objet interne, et probablement augmenter inutilement la visibilité de certains attributs/méthodes de l'ex-classe externe.
...et permet en outre de gérer ce pattern singleton.
1. il y a des cas qui se prettent pas naturellement au pattern singleton
2. on peut faire un sigleton avec une classe interne aussi bien qu'avec une classe dans un fichier séparé
3. avec une classe anonyme on peut faire la même chose :
static private WindowListener listener = new WindowListener() {
public void windowClosed() { /* blah blah */ }
});
et ensuite : addListener(listener);
Après, si le développeur ne sait pas réutiliser des objets, ... (en gros qu'il ne sait pas faire de prog objet correctement), il ne faut pas mettre ça sur le dos du langage...-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Guillaume Laurent (page perso, ) le 08/06/2003 à 07:53. (lien). Évalué à 1.Après, si le développeur ne sait pas réutiliser des objets, ... (en gros qu'il ne sait pas faire de prog objet correctement)
Ah, parce que réutiliser des objets c'est de la programmation objet "correcte" ? Il me semble au contraire que c'est parce qu'il est toujours trop couteux en Java de créer des objets qu'on est obligé de les réutiliser.
C'est clairement un des points ou Java a totalement échoué : la façon "instinctive" d'utiliser le langage fait écrire du code pas performant. Il faut apprendre des techniques pas du tout triviales pour éviter ça, et ça complexifie d'autant l'écriture des programmes. C++ a le même problème mais pas sur la création d'objet (plutôt sur les affectations, la manière "instinctive" de faire induit des plantages ou des fuites de mémoire).
Après, évidemment les "experts" disent "ah mais oui si tu fais comme ça c'est que tu sais pas coder". Non, c'est faux. C'est le langage qui est mal conçu.-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Pierre Tramo (page perso, ) le 08/06/2003 à 12:17. (lien). Évalué à 1.Ah, parce que réutiliser des objets c'est de la programmation objet "correcte" ?
Suivant les cas, oui.
Il me semble au contraire que c'est parce qu'il est toujours trop couteux en Java de créer des objets qu'on est obligé de les réutiliser.
La création d'un objet nécessite une allocation mémoire, c'est une opération coûteuse dans tous les langages.
C'est clairement un des points ou Java a totalement échoué : la façon "instinctive" d'utiliser le langage fait écrire du code pas performant. Il faut apprendre des techniques pas du tout triviales pour éviter ça, et ça complexifie d'autant l'écriture des programmes.
Tous les langages et toutes les méthodes de programmation nécessitent un apprentissage...
Après, évidemment les "experts" disent "ah mais oui si tu fais comme ça c'est que tu sais pas coder". Non, c'est faux. C'est le langage qui est mal conçu.
Ah ? Tous les langages dans lesquels le premier venu peut coder comme un goret sont des langages mal conçus ? Il ne doit pas y avoir des masses de langages bien conçus alors...-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Guillaume Laurent (page perso, ) le 09/06/2003 à 08:54. (lien). Évalué à 1.Suivant les cas, oui.
A part les cas où c'est nécéssaire pour des raisons de performances, à quels cas penses-tu ?
La création d'un objet nécessite une allocation mémoire, c'est une opération coûteuse dans tous les langages.
Non. En C++, si tu crée un "petit" objet sur la stack, ça n'est pas très couteux...
Tous les langages et toutes les méthodes de programmation nécessitent un apprentissage...
Tu n'as pas compris : si tu apprends la programmation objet, en général la réutilisation des objets ne sera pas présenté comme un concept de base, bien au contraire. Ça sera plutôt dans la section "trucs et astuces si votre programme rame vraiment trop".
Ah ? Tous les langages dans lesquels le premier venu peut coder comme un goret sont des langages mal conçus ? Il ne doit pas y avoir des masses de langages bien conçus alors...
Je ne parle pas du "premier venu". Ceci dit, oui, il n'y a pas beaucoup de langages bien conçus sur ce plan là (je ne connais que Python et Ruby qui s'en sortent).
-
-
-
-
-
-
-
-
-
[+] [^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par boubou (page perso, ) le 05/06/2003 à 17:01. (lien). Évalué à -2.Ta bien raison de ne pas être convaincu, parce que c'est une grosse connerie.
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par alpage (Jabber id, page perso, ) le 05/06/2003 à 09:57. (lien). Évalué à 3.Mais ces fameux programmes rapides écrits en Java, où sont-ils !?!
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Christophe Badoit (page perso, ) le 05/06/2003 à 10:45. (lien). Évalué à 2.J'ai en tête Arkanae (bien que un peu vieux maintenant), développé par 2 personnes, et qui utilise opengl. C'est impresionnant...
http://arkanae.tuxfamily.org/fr/index.html(...)
Mais tu veux tester la vitesse, écrit un programme en java (pas d'awt, juste un truc en console) et compare ! Mais ne lance pas une calculatrice en applet java dans mozilla, c'est pas vraiment une référence...-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par gnumdk (page perso, ) le 05/06/2003 à 14:02. (lien). Évalué à 2.arkanae, le mauvais exemple.... :)
Alors la, je te contredis tout de suite, quand je dis que java rame(et je le dit), c'est le temps d'initialisation du programme qui je prend en compte, apres, effectivement, arkanae se defend bien meme si il y'a un peu de lag par moment...
Par exemple cube(ecrit en C) se lance instantanément tandis que arkanae, c'est loin d'etre rapide...
http://wouter.fov120.com/cube/(...)
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Moby-Dik () le 05/06/2003 à 10:46. (lien). Évalué à 4.En Irak, à côté des armes de destruction massive.
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Pierre Tramal (page perso, ) le 05/06/2003 à 14:53. (lien). Évalué à 3.bon, je me lance, même avec une moyenne de score à 2.0 je ne peux pas voter donc voilà:
DTC!
Daizaulait-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
-
-
[^]Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Nicolas Delsaux (
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.