IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Pour ou Contre le Garbage Collector ?


Sujet :

Débats sur le développement - Le Best Of

  1. #141
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 584
    Points : 1 374
    Points
    1 374
    Par défaut
    Citation Envoyé par deneb
    Le problème c'est qu'un jour ou l'autre, tout ce que tu n'as pas vraiment géré et prévu te revient dans la tronche violemment.
    Après c'est un problème de fréquence et de temps passé à résoudre le problème comparativement au temps passé à toujours penser à la gestion de la mémoire.

    Dans mon cas, bien qu'utilisant du java au quotidien (appli web), je n'ai jamais créé de nouveaux threads. De plus, tant mon travail que celui de mes plusieurs collègues ne nous a jamais pété à la tronche comme tu dis.

    Par contre, un oubli dans la taille de ton malloc m'avait couté très très cher à l'époque

    De plus, un gars qui créé 200 000 threads sans penser à les gérer plus que ça il a non seulement des problèmes dans son code mais aussi et surtout dans sa conception !

    Dans la même veine, j'aimerai vraiment voir la tête des erreurs qui t'ont pété à la figure. Ne serait ce pas des cas bien particuliers où même les habitudes "standards/de base" d'un développeur C++ inattentif n'auraient pas fait la différence ?

    Et là encore, au demeurant, qu'en est il de la conception derrière, de la revue de la dite conception, de la revue du code, des tests de perfs et ainsi de suite ?

    Bref, dans mon quotidien je ne vois pas le besoin d'une gestion manuelle. Devoir penser à la mémoire des fois, oui, bien sûr, et merci de le rappeller pour ceux qui auraient oubliés, mais de là à la gérer tout le temps à la main...

    Comme dit plus haut, par contre, je ne nie pas que dans certains cas très précis (gestion de la mémoire à l'octet, environnement très très contraint), le manque de gestion plus manuelle peut venir à manquer.

    Et encore, dans le cas de l'environnement très contraint (volume de données, nombres d'échanges), la conception est aussi des plus primordiales, ainsi que le choix des outils, et je serai très surpris de voir que les perfs d'un ensemble complexe ne découlent que des choix d'un petit développeur dans son coin qui gère mal un ensemble de threads...

    D'ailleurs, il y a du java qui tourne dans des environnements avec forte charge, ça veut bien dire que ce n'est pas impossible. Et d'ailleurs je ne suis pas certain que concevoir un tel bébé en Java soit plus compliqué que de concevoir la chose avec un langage ayant une gestion manuelle de la mémoire. La gestion automatique de la mémoire va aussi enlever une part du souci et des inquiétudes des concepteurs.

    Bref, je ne vois que les environnements où la gestion de la mémoire est à l'octet près où le Java est, à priori, peu recommandé. Mais bon, ces environnements sont de moins en moins nombreux, je ne m'inquiète pas. Et après, suffit de voir le succès de Java sur les mobiles !

    Attention, je ne dis pas que le GC de Java soit parfait, je dis juste "dans 95 % des cas la gestion automatique de la mémoire est préférable, selon moi", vu les arguments énoncés ci dessus.

    Après, c'est pas une solution miracle, le mec qui oublit de gérer ses threads ou fait une conception boiteuse ne pourra pas compter sur le language et la plate forme pour tout faire pour lui. Et encore heureux !
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  2. #142
    Expert éminent sénior
    Avatar de sinok
    Profil pro
    Inscrit en
    Août 2004
    Messages
    8 765
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2004
    Messages : 8 765
    Points : 12 977
    Points
    12 977
    Par défaut
    Citation Envoyé par Zedros
    Dans mon cas, bien qu'utilisant du java au quotidien (appli web), je n'ai jamais créé de nouveaux threads. De plus, tant mon travail que celui de mes plusieurs collègues ne nous a jamais pété à la tronche comme tu dis.
    Dans ce cas tu ne fais qu'utiliser un serveur, il est donc normal que le nombre de threads que tu doive utiliser soit nul ou très faible. Par contre e serveur que tu utilise peut lui émettre un bon paquet de threads, tout dépend de comment il a été réalisé.

    Ensuite pour y revenir au problème des threads pour un serveur, un bon développeur java doit savoir qu'il existe nio et les méthodes accept non bloquantes, ce qui permet de réduire un serveur à un seul thread pour les connexions (ensuite il reste les threads autres correspondant aux actions longues mais là c'est une autre histoire), et donc utiliser largement moins de mémoire (par contre plus de processeur, relation de cause à effet oblige).
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  3. #143
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    Citation Envoyé par deneb
    C'est lié !
    Un développeur, même très bon, mais qui n'a jamais développé dans un autre language que Java, n'acquiers pas les bons reflexes.

    J'ai aussi vu de bons développeurs très expérimentés faire des bourdes plus graves encore (moi le premier ), car quand on passe à Java, petit à petit on ne se pose plus la moindre question : on fait comme certains l'ont très bien dit : "confiance aux mecs de Sun qui ont du bien bosser pour que je puisse me consacrer uniquement au métier".
    Le problème c'est qu'un jour ou l'autre, tout ce que tu n'as pas vraiment géré et prévu te revient dans la tronche violemment.
    C'est pas trop ce que j'appelle de bons développeurs ça.

    Enfin, ce que je veux dire, précisément, c'est que quand tu fais ta connerie "je fais confiance à Sun" ou tout autre truc du genre qui au final te revient sur la gueule, c'est que tu as mal fait ton boulot quelque part, que c'est de ta faute à toi, pas à celle du GC.

    Un peu trop facile de dire : "oui, notre programme est over-buggué, mais c'est pas de notre faute, c'est la faute de Sun qui a intégré un outil dont nous n'avons pas l'habitude de nous servir".

    Ceci dit, je pense pas qu'un débat tournant autour du thème "qu'est-ce qui est mieux, un développeur qui fait bien son boulot sans GC ou bien un développeur qui fait pas bien son boulot avec GC ?" ait un quelconque intérêt.

  4. #144
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    Décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2004
    Messages : 2 493
    Points : 4 166
    Points
    4 166
    Par défaut
    Citation Envoyé par sinok
    Ensuite pour y revenir au problème des threads pour un serveur, un bon développeur java doit savoir qu'il existe nio et les méthodes accept non bloquantes, ce qui permet de réduire un serveur à un seul thread pour les connexions (ensuite il reste les threads autres correspondant aux actions longues mais là c'est une autre histoire), et donc utiliser largement moins de mémoire (par contre plus de processeur, relation de cause à effet oblige).
    Tout cela n'est qu'un probleme de choix de conception :
    > n requêtes-n threads ?
    > n requêtes-1 thread facade puis délégation à n threads ?
    > n requêtes-1 thread facade puis délégation à n threads pré-chargés dans un pool ?
    > etc.

    Oui, il y a des choix de conceptions qui sont meilleures que d'autres selon le contexte (voir Design patterns). Oui, il y a des structures de données moins gourmandes que d'autre. Mais quel est le rapport de tout cela avec le débat désallocation manuelle vs. automatisée de la mémoire ?
    Tu n'es pas le premier à citer ce genre d'exemple du quotidien (néanmoins intéressants ) dans lesquels je n'y vois que des problèmatiques de conception.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  5. #145
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par davcha
    C'est pas trop ce que j'appelle de bons développeurs ça.
    Enfin, ce que je veux dire, précisément, c'est que quand tu fais ta connerie "je fais confiance à Sun" ou tout autre truc du genre qui au final te revient sur la gueule, c'est que tu as mal fait ton boulot quelque part, que c'est de ta faute à toi, pas à celle du GC.
    Tu ne les connais pas. Certains sont peut-être meilleurs que toi qui te prend pour un maître !
    Citation Envoyé par davcha
    Un peu trop facile de dire : "oui, notre programme est over-buggué, mais c'est pas de notre faute, c'est la faute de Sun qui a intégré un outil dont nous n'avons pas l'habitude de nous servir".
    Notre appli n'est pas over bugguée et personne renvoie la faute sur Sun. Ils ont fait du très bon boulot...et j'irais même jusqu'à dire que le GC est un perle de développement.
    Par contre ce que j'affirme c'est que plus on déresponsabilise un développeur en lui machant le travail...et moins il se pose de questions. C'est parfaitement humain.
    Tu as exactement les mêmes problèmes en matière de management. Quand tu confie un poste à un collaborateur, au début tu vérifie que le boulot est bien fait, et puis au fil du temps tu relaches ton attention, tu fais confiance...et un jour inévitablement la connerie arrive.
    Citation Envoyé par davcha
    Ceci dit, je pense pas qu'un débat tournant autour du thème "qu'est-ce qui est mieux, un développeur qui fait bien son boulot sans GC ou bien un développeur qui fait pas bien son boulot avec GC ?" ait un quelconque intérêt.
    Je vais essayer d'être un peu plus constructif que toi...
    Un outil sensé apporter de la qualité en prenant en charge une partie sensible du travail mais qui au final induit inévitablement d'autres problèmes tout aussi graves (cf les centaines de sujet là dessus sur le web)...a t'il vraiment un intéret ?
    C'est un débat de fond qui vaut pour tous les outils d'aide au développement : que ce soit un GC, un outil de mapping O/R ou un wizard IHM.

  6. #146
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 584
    Points : 1 374
    Points
    1 374
    Par défaut
    Citation Envoyé par deneb
    Tu as exactement les mêmes problèmes en matière de management. Quand tu confie un poste à un collaborateur, au début tu vérifie que le boulot est bien fait, et puis au fil du temps tu relaches ton attention, tu fais confiance...et un jour inévitablement la connerie arrive.
    Le même problème se pose avec la gestion manuelle de la mémoire, en étant encore plus dramatique car les retombés peuvent être bien plus pernicieuses !

    Après, faut arrêter de dire que le GC "déresponsabilise" le développeur. C'est faux, archi faux ! Il lui facilite la tâche, oui, mais in fine c'est toujours le développeur qui est responsable. A lui de de faire attention et d'utiliser les bons outils en connaissance de cause.
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  7. #147
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    Décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2004
    Messages : 2 493
    Points : 4 166
    Points
    4 166
    Par défaut
    Citation Envoyé par deneb
    Par contre ce que j'affirme c'est que plus on déresponsabilise un développeur en lui machant le travail...et moins il se pose de questions. C'est parfaitement humain.
    "Déresponsabiliser" me semble un peu fort mais en revanche tu as parfaitement raison de dire qu'on se pose moins de questions de ce coté là, mais c'est voulu. En effet, ce que tu oublies de dire, c'est que le travail économisé de ce coté permet de se consacrer d'avantage aux problématiques de conception et métiers. Les préoccupations se déplacent avec l'émergence des systèmes informatiques de plus en plus complexes (larges echelles, distribués, hétérogènes, nomades, ...). C'est cela qu'il faut bien comprendre. L'informatique a profondement évoluée et n'est plus celle d'il y a 10 ou 20 ans. S'accrocher à une gestion mémoire manuelle ou un mapping O/R à la main n'est plus la tendance. C'est un fait, il faut déléguer un maximum de chose aux frameworks et middlewares pour faire face aux nouveaux défis de l'ingénierie du logiciel.

    Je ne peux évidemment pas vous reprocher de gérer finement la mémoire, le mapping O/R, où le code IHM, mais dans ce cas vous êtes fortement handicapés dans la course aux logiciels de demain où la complexité explose et où le time-to-market diminue.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  8. #148
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par ZedroS
    Le même problème se pose avec la gestion manuelle de la mémoire, en étant encore plus dramatique car les retombés peuvent être bien plus pernicieuses !

    Après, faut arrêter de dire que le GC "déresponsabilise" le développeur. C'est faux, archi faux ! Il lui facilite la tâche, oui, mais in fine c'est toujours le développeur qui est responsable. A lui de de faire attention et d'utiliser les bons outils en connaissance de cause.
    Tout à fait exact...mails il va falloir expliquer ça :
    1. aux profs des facs et autres écoles d'ingé.
    2. aux mecs qui écrivent des tuto sur le web (y compris ici).
    3. aux mecs qui écrivent des manuel de Java.
    Pour ce qui est de faciliter la tâche...mwouaih bof.
    Entre respecter des patterns d'allocation/libération relativement simples et immuables et être obligé de connaitre CA je ne sais pas ce qui demande le plus de boulot.

  9. #149
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par Hephaistos007
    ...

    Je ne peux évidemment pas vous reprocher de gérer finement la mémoire, le mapping O/R, où le code IHM, mais dans ce cas vous êtes fortement handicapés dans la course aux logiciels de demain où la complexité explose et où le time-to-market diminue.
    Oh une prophétie !! Merci ami
    Plus sérieusement, quand on fait des softs vraiment complexes (pas des pages JSP )...les outils "d'aide" finissent par faire perdre plus de temps qu'ils n'en font gagner. Ces outils marchent très bien dans le cas "nominal"...cad le cas d'école, pas trop compliqué. Dès que tu commence à flirter avec les limites de ces outils la perte de temps pour contourner le problème devient exponentielle et à vite fait de te faire reperdre tout le temps gagné.

  10. #150
    Membre habitué
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Mars 2004
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2004
    Messages : 102
    Points : 156
    Points
    156
    Par défaut Pragmatisme
    Il est évident que dans des applications lourdes et complexes en java, ne pas tenir compte des allocations mémoire amènent droit à la catastrophe.
    Il est impératif de tenir compte :
    - de la taille des objets créés
    - de la fréquence à laquelle ces objets sont créés.

    Il faut donc étudier au cas par cas s'il faut se substituer au GC. Cela peut aller loin : dans notre application de gestion d'images, nous avons été obligé de réécrire les classes représentant les images pour allouer/désallouer les tableaux représentant les données des images, mais on laisse le GC s'occuper des chaînes de caractères !

  11. #151
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par hedes
    Il est évident que dans des applications lourdes et complexes en java, ne pas tenir compte des allocations mémoire amènent droit à la catastrophe.
    Il est impératif de tenir compte :
    - de la taille des objets créés
    - de la fréquence à laquelle ces objets sont créés.

    Il faut donc étudier au cas par cas s'il faut se substituer au GC. Cela peut aller loin : dans notre application de gestion d'images, nous avons été obligé de réécrire les classes représentant les images pour allouer/désallouer les tableaux représentant les données des images, mais on laisse le GC s'occuper des chaînes de caractères !
    Enfin quelqu'un de réaliste
    Et je ne pense pas dire une grosse connerie en affirmant qu'il manque à Java des outils pour gerer un peu plus la mémoire "à la main" quand on en a besoin.
    En fait c'est tout de le problèmes des outils "fermés" qui prennent en charge tout le travail et ne laissent pas le développeur en faire une partie si ça lui chante. Par exemple les outils de mapping O/R font gagner beaucoup de temps de dev, mais ont des performances dramatiques dans certaines circonstances...Dans ces cas là la plupart (aux moins ceux que je connais, donc Toplink et hibernate) autorise le developpeur à passer derriere le mirroir pour faire le taf "à la main".
    C'est ça qui manque au GC.

  12. #152
    Membre habitué
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Mars 2004
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2004
    Messages : 102
    Points : 156
    Points
    156
    Par défaut Outils
    En fait, pour notre part, les solutions mises en place ont été très simples : pour les images, une interface avec alloc->buffer, free(buffer) et utilisation des "weak reference". Ce style de solution est donc de bas niveau et mise en place lors de l'intégration quand on se rend compte que cela pète. Précision importante : les buffers sont de taille standard.

    Les autres objets qui peuvent poser problème représentent des données contenus dans la base de données : on a mis en place un cache où les objets sont stockés lors de leur création. Par la suite, ils sont mis à jour et jamais recréés. Ce type de solution est de plus haut niveau et doit être pensé dès le début du projet.

    Avec ça, on n'a pas de soucis de mémoire.

    A vous de conclure...

  13. #153
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    Citation Envoyé par deneb
    Tu ne les connais pas. Certains sont peut-être meilleurs que toi qui te prend pour un maître !
    [... blablabla davcha est un vilain pas beau pas constructif... blabla...]
    On s'est mal compris je crois.

    Je ne vous ai pas dit que vous étiez de mauvais développeurs, que j'étais meilleur que vous et encore moins que j'étais un maître.

    Ce que j'ai dit, en espérant être clair cette fois, c'est : un développeur qui se déresponsabilise totalement, comme vous dites, ne fait certainement pas son boulot (celui qu'il est en train de faire) correctement.
    Autrement dit, le jour où n'importe quel développeur (y compris vous, y compris moi) fait un programme qui plante sans arrêt, qui demande 50 fois trop de ressources matérielles, etc... Bah il a pas fait son boulot correctement, c'est clair.
    Et ça, c'est pas la faute du GC, c'est de sa faute à lui.

    Ceci dit, si l'utilisation du GC se révèle trop problématique dans certains cas, pourquoi utiliser le GC dans ces cas précis ?
    Et si l'utilisation du GC fait des merveilles dans d'autres cas, pourquoi s'en passer ?

    Voilà, y'avait rien de "haineux" dans mon précédent message (ni dans celui-ci d'ailleurs).

  14. #154
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Au fond on est d'accord...
    En fait je crois que notre différence d'appréciation vient simplement du fait que vous considérez le problème d'un point de vue de développeur, qui plus est, sensibilisé à ces problèmes particuliers.
    Moi je vois la chose sous l'angle du patron d'une boite d'édition, qui développe certe encore un peu en hobbiste mais avec surtout la responsabilité d'une équipe de développement.
    Or dans ce contexte je sais pertinement que si on donne la possibilité à un collaborateur de se décharger quasi totalement d'une tâche, il s'en détachera un jour ou l'autre ... totalement.

    Je voulais juste ajouter que d'un point de vue de manager il est moins important de savoir si un disfonctionnement provient d'une erreur d'un collaborateur ou de ses compétences, que de mettre en place un cadre qui dirige les travaux dans le bon sens.
    En cela, je trouve que le GC est dangereux (tout comme les outils de mapping O/R ou les wizards IHM).
    A une époque je disais, toujours avec un brin de provoc , que "seuls ceux qui ont déjà travaillé en assembleur devraient faire du C, et que seuls ceux qui ont travaillé en C devraient faire du Java". Et ça reste pour moi d'actualité : quand on utilise des outils très évolué comme le GC ou Hibernate, il est indispensable d'avoir une vision assez fine du travail réel que va faire l'outil.

  15. #155
    Nouveau Candidat au Club
    Inscrit en
    Septembre 2006
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : Septembre 2006
    Messages : 1
    Points : 1
    Points
    1
    Par défaut whyyyyy??
    Citation Envoyé par deneb
    C'est un truc maintes fois vu ici : le GC permet de mieux sans sortir quand on programme comme un cochon.
    C'est comme ça que je retrouve le code suivant dans notre appli :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public void mouseMove(MouseEvent mouseEvent) 
    {
    	Point mousePosition = new Point(mouseEvent.x , mouseEvent.y);
    
       	//calculs utilisant mousePosition.
    }
    Alors oui dans ce cas, le GC s'en sortira mieux qu'une désallocation manuelle.
    Mais on est là dans un cas type de mauvais usage de la mémoire.
    alors je vais ptet passer pour un newbie mais comme j'ai jamais eu d'autres expérience que le java... pourkoi ton bout de code est un cas typique de mauvais usage de la mémoire ?

    je lis depuis tout à l'heure les pour et les contres de gc mais moi j'aimerai savoir justement à ceux qui semble savoir gérer trés bien la mémoire en java, comment on fait ???? donner des exemples... et expliquer les ... ce sera moins philosophique et plus concret ! et ça aménera un peu d'eau au moulin !

  16. #156
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par bugger
    alors je vais ptet passer pour un newbie mais comme j'ai jamais eu d'autres expérience que le java... pourkoi ton bout de code est un cas typique de mauvais usage de la mémoire ?

    je lis depuis tout à l'heure les pour et les contres de gc mais moi j'aimerai savoir justement à ceux qui semble savoir gérer trés bien la mémoire en java, comment on fait ???? donner des exemples... et expliquer les ... ce sera moins philosophique et plus concret ! et ça aménera un peu d'eau au moulin !
    le problème c'est de faire une allocation (new Point) à chaque exécution de la méthode.
    Evidemment ça parait pas grave comme ça hein ? C'est qu'un petit objet un Point après tout.
    Le problème c'est qu'une méthode mouseMove, avec un utilisateur qui trimballe sa souris en permanence, tu peux en avoir plusieurs dizaines par seconde...et chaque fois tu rajoute en mémoire un objet Point qui ne sert plus à rien.
    Au bout de quelques minutes, tu as accumulé plusieurs milliers d'instances mortes qu'il va falloir ramasser.
    Alors qu'avec une allocation "statique", à l'instanciation du composant par exemple, aucune ressource supplémentaire n'est consommée.
    Pas besoin d'allouer de la mémoire, ni de la ramasser.

  17. #157
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 584
    Points : 1 374
    Points
    1 374
    Par défaut
    Citation Envoyé par deneb
    le problème c'est de faire une allocation (new Point) à chaque exécution de la méthode.
    Hum, d'après ce que j'ai vu la techno HotSpot de la JVM est à même d'intervenir dans ces cas là et de faire du réusage de variable. Cependant, je n'ai pas réussi à trouver de confirmation précise de ce point du coté des docs Sun alors je ne sais pas trop. Je suis un peu dans l'expectative, sans être certain que ce soit une faute et/ou corrigé.

    Au demeurant, c'est le seul réel exemple de mauvaise pratique que nous ayons trouvé jusqu'ici en + de 10 pages de discussion.

    Aussi, si le seul gros souci avec le GC est ce type d'erreur, alors la solution est simple :
    - pousser les VM Java/.Net à savoir passer outre
    - éduquer les développeurs Java/.Net sur ce point
    et c'est tout.

    Mais avant, faudra me prouver que la JVM ne traite pas ce genre de cas et qu'avec l'allocation/Désallocation de mémoire par zones ce genre de cas est réellement un problème.
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  18. #158
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 584
    Points : 1 374
    Points
    1 374
    Par défaut
    Citation Envoyé par deneb
    Je voulais juste ajouter (pourquoi ne puis-je éditer mes messages d'ailleurs ?) que d'un point de vue de manager il est moins important de savoir si un disfonctionnement provient d'une erreur d'un collaborateur ou de ses compétences, que de mettre en place un cadre qui dirige les travaux dans le bon sens.
    En cela, je trouve que le GC est dangereux (tout comme les outils de mapping O/R ou les wizards IHM).
    C'est quoi le rapport avec le manager ? Tu crois que faute de comprendre le GC il va dire "ouaip ben retour à la gestion manuelle de la mémoire!" ???

    En effet, je rappelle que le sujet de thread, et donc la source des réponses de bien des personnes, est "Pour ou contre le GC ?".

    Pour l'instant, deneb, j'ai la furieuse impression que tu oscilles entre des passages clairement anti GC, qui se font démonter, et des passages où tu pointes du doigt des améliorations, où les gens approuvent, en bouclant et et relançant sans fin le débât. Quelque chose de tout sauf cohérent et très usant à lire.

    Moralité, sommes nous d'accord sur :
    1 - Oui, la GC est une réelle avancée dans les applications sans gestion à l'octet de la mémoire/temps réel dur.
    2 - Oui la GC est perfectible, toutes les contributions (constructives) sont les bienvenues !
    Oui ou non ?

    La première partie aura clot le présent débât
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  19. #159
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par ZedroS
    Hum, d'après ce que j'ai vu la techno HotSpot de la JVM est à même d'intervenir dans ces cas là et de faire du réusage de variable. Cependant, je n'ai pas réussi à trouver de confirmation précise de ce point du coté des docs Sun alors je ne sais pas trop. Je suis un peu dans l'expectative, sans être certain que ce soit une faute et/ou corrigé.
    ...
    Mais avant, faudra me prouver que la JVM ne traite pas ce genre de cas et qu'avec l'allocation/Désallocation de mémoire par zones ce genre de cas est réellement un problème.
    Le simple fait que ce type d'optimisation existe me hérise le poil.
    Autant dire aux développeurs : allez-y codez comme des porcs, le compilo recollera les morceaux.
    Il y aura toujours un paquet de fautes qu'il ne saura pas rattraper...

  20. #160
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 56
    Points : 33
    Points
    33
    Par défaut
    Citation Envoyé par ZedroS
    C'est quoi le rapport avec le manager ? Tu crois que faute de comprendre le GC il va dire "ouaip ben retour à la gestion manuelle de la mémoire!" ???

    En effet, je rappelle que le sujet de thread, et donc la source des réponses de bien des personnes, est "Pour ou contre le GC ?".

    Pour l'instant, deneb, j'ai la furieuse impression que tu oscilles entre des passages clairement anti GC, qui se font démonter, et des passages où tu pointes du doigt des améliorations, où les gens approuvent, en bouclant et et relançant sans fin le débât. Quelque chose de tout sauf cohérent et très usant à lire.

    Moralité, sommes nous d'accord sur :
    1 - Oui, la GC est une réelle avancée dans les applications sans gestion à l'octet de la mémoire/temps réel dur.
    2 - Oui la GC est perfectible, toutes les contributions (constructives) sont les bienvenues ! Oui ou non ?

    La première partie aura clot le présent débât
    Personne ne t'oblige à lire et encore moins à participer à des discussions "usantes", qui jusqu'à preuve du contraire n'ont pas d'autre but que de ...discuter !
    On n'est pas sur la section "comment on fait un new ?" !
    Sinon je n'oscille pas...je n'aime pas cet outil. Et en tant que manager si j'avais la possibilité de dire à mes équipes de gérer la mémoire à la main je le ferais sans hésitation.
    Mais je suis réaliste et je sais que Java n'ira jamais sans GC, donc je propose des améliorations...

Discussions similaires

  1. Garbage collector en C++, pour ou contre ?
    Par Klaim dans le forum C++
    Réponses: 70
    Dernier message: 05/08/2010, 15h03
  2. Le Garbage collector est-il fait pour cela ?
    Par macRiaz dans le forum Android
    Réponses: 16
    Dernier message: 24/02/2010, 01h01
  3. Réponses: 12
    Dernier message: 29/06/2009, 08h20
  4. Réponses: 1
    Dernier message: 03/06/2009, 01h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo