Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.
Ça n'est pas la partie critique.
Bref les GC modernes ne sont pas un problème dans les jeux.
On ne les utilise pas dans les parties critiques donc ce n'est pas un problème ? Soit.
Dis autrement ce n'est pas une question de performance des gc qui permet ça. Juste qu'on a construit des frameworks pour dissocier la partie critique de l'application. C'est une très bonne chose, hein pas une critique du tout.
Ni dans les applis web
Là c'est encore très différent. Pour un deamon qui aura par nature une durée de vie plus longue, c'est bien plus simple d'utiliser un gc pour limiter la fragmentation mémoire. Mais même comme ça les appli qui ont une certaine criticité vont faire du off the heap.
ni dans 99% des applis
De mon avis perso, « 99 % des appli » devraient plus s'intéresser à la correction qu'à la performance et donc éviter à tout prix de manipuler à la main la mémoire.
[^] # Re: Pffff
Posté par barmic 🦦 . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 2. Dernière modification le 08 septembre 2020 à 15:17.
Ça n'est pas la partie critique.
On ne les utilise pas dans les parties critiques donc ce n'est pas un problème ? Soit.
Dis autrement ce n'est pas une question de performance des gc qui permet ça. Juste qu'on a construit des frameworks pour dissocier la partie critique de l'application. C'est une très bonne chose, hein pas une critique du tout.
Là c'est encore très différent. Pour un deamon qui aura par nature une durée de vie plus longue, c'est bien plus simple d'utiliser un gc pour limiter la fragmentation mémoire. Mais même comme ça les appli qui ont une certaine criticité vont faire du off the heap.
De mon avis perso, « 99 % des appli » devraient plus s'intéresser à la correction qu'à la performance et donc éviter à tout prix de manipuler à la main la mémoire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll