Donc, au bout du compte, tu développes longuement en te reposant sur le garbage. Et à la fin, très fréquemment, tu te rends compte que le système laggue monstrueusement après quelques heures/jours d'utilisation parce que le GC à de plus en plus de mal sans aide.
C'est faux. Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème. Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre. Si tu as ce genre de problème de performance c'est que quelque part tu garde des références vers des objets que le gc ne pourra donc jamais désallouer. Tu peut régler ça avec des reboot ou en nullifiant les références en question si tu n'a pas le temps de réfléchir au problème, mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la réponse est évidente
Posté par barmic . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
C'est faux. Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème. Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre. Si tu as ce genre de problème de performance c'est que quelque part tu garde des références vers des objets que le gc ne pourra donc jamais désallouer. Tu peut régler ça avec des reboot ou en nullifiant les références en question si tu n'a pas le temps de réfléchir au problème, mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)