Très franchement, en lisant l'article, je ne sais pas vraiment quoi en déduire. En tout cas, je ne suis pas convaincu.
En effet, le code optimisé est très efficace, mais :
On passe d'un code lisible (je comprends bien ce qu'il fait, sans connaître C#) à un code dont la fonction de base est noyée dans les optimisations
Le résultat est rapide, principalement parce que... le GC n'a plus rien à faire. On précalcule, on réutilise des buffers, etc. Donc OK, le code est rapide, mais on peut très bien en conclure l'opposé de ce que tu sembles indiquer: dans ce langage avec GC, une façon d'obtenir de bons résultats est d'éviter ce boulet de GC.
# Mes impressions
Posté par Christophe . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 10.
Très franchement, en lisant l'article, je ne sais pas vraiment quoi en déduire. En tout cas, je ne suis pas convaincu.
En effet, le code optimisé est très efficace, mais :
On passe d'un code lisible (je comprends bien ce qu'il fait, sans connaître C#) à un code dont la fonction de base est noyée dans les optimisations
Le résultat est rapide, principalement parce que... le GC n'a plus rien à faire. On précalcule, on réutilise des buffers, etc. Donc OK, le code est rapide, mais on peut très bien en conclure l'opposé de ce que tu sembles indiquer: dans ce langage avec GC, une façon d'obtenir de bons résultats est d'éviter ce boulet de GC.