Si un logiciel équivalent est écrit avec un ramasse miettes de merde, il va consommer dés le début 120Mo de trop, sans amélioration possible.
Tout l'intérêt du ramasse-miettes intégré au langage, c'est qu'au lieu d'avoir un "ramasse-miettes de merde" spécifique à chaque logiciel un peu compliqué, tu as une plateforme commune qui est relativement mûrie et débuggée, et bien réglée (ou réglable, d'ailleurs).
C'est comme un compilateur : ça abstrait et mutualise un travail fastidieux (la traduction d'instructions haut niveau en code assembleur) au prix d'une petite perte potentielle d'efficacité par rapport à l'écriture d'une gestion bas niveau écrite à la main.
Après il y a toujours des inconditionnels de l'écriture d'ASM à la main mais, s'ils étaient encore nombreux dans les années 90, ils sont totalement marginaux aujourd'hui et font figure (fort compréhensiblement) de gentils zozos.
Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.
N'importe quoi. Correctement testé ne veut pas dire que tous les cas de figures sont prévisibles, et exhaustivement énumérables (sauf logiciel très simple). C'est d'autant plus le cas si le logiciel est multithreadé, d'ailleurs, à cause des problèmes très subtils que cela peut entraîner.
Dans le cas de Python, on trouve encore aujourd'hui des problèmes de gestion mémoire sur du code écrit parfois il y a 10 ou 15 ans. Je parle évidemment de l'interpréteur Python, plus précisément de la partie écrite en C... Après, libre à toi de penser qu'on fait de la merde et que tu es plus compétent.
[^] # Re: ...
Posté par Antoine . En réponse à la dépêche GNOME 2.30.2, dernières révérences de l'honorable. Évalué à -1.
Tout l'intérêt du ramasse-miettes intégré au langage, c'est qu'au lieu d'avoir un "ramasse-miettes de merde" spécifique à chaque logiciel un peu compliqué, tu as une plateforme commune qui est relativement mûrie et débuggée, et bien réglée (ou réglable, d'ailleurs).
C'est comme un compilateur : ça abstrait et mutualise un travail fastidieux (la traduction d'instructions haut niveau en code assembleur) au prix d'une petite perte potentielle d'efficacité par rapport à l'écriture d'une gestion bas niveau écrite à la main.
Après il y a toujours des inconditionnels de l'écriture d'ASM à la main mais, s'ils étaient encore nombreux dans les années 90, ils sont totalement marginaux aujourd'hui et font figure (fort compréhensiblement) de gentils zozos.
Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.
N'importe quoi. Correctement testé ne veut pas dire que tous les cas de figures sont prévisibles, et exhaustivement énumérables (sauf logiciel très simple). C'est d'autant plus le cas si le logiciel est multithreadé, d'ailleurs, à cause des problèmes très subtils que cela peut entraîner.
Dans le cas de Python, on trouve encore aujourd'hui des problèmes de gestion mémoire sur du code écrit parfois il y a 10 ou 15 ans. Je parle évidemment de l'interpréteur Python, plus précisément de la partie écrite en C... Après, libre à toi de penser qu'on fait de la merde et que tu es plus compétent.