Posté par Antoine .
En réponse à la dépêche Python 3.3 est sorti.
Évalué à 5.
Dernière modification le 03 octobre 2012 à 20:29.
Par exmple il y a probablement plus de conversions à la volée maintenant lorsqu'on itère sur les caractères non?
Itérer sur les caractères est une opération triviale et, dans ce cas, c'est la boucle d'évaluation de CPython qui sera le facteur dominant.
Par contre, là où ça peut être plus lent, c'est dans certaines créations de chaînes en combinant des chaînes utilisant des représentations différentes (par exemple : une concaténation, ou bien un appel à la méthode str.replace()). Cela ne se remarquera vraiment que sur des chaînes très longues, donc pas les cas les plus courants.
(en contrepartie, il y a aussi certaines opérations qui deviennent plus rapides, par exemple décoder en utf-8 une chaîne d'octets qui s'avérerait être purement ASCII : ce cas est optimisé comme un simple memcpy())
[^] # Re: strings: Optimisation mémoire vs cpu?
Posté par Antoine . En réponse à la dépêche Python 3.3 est sorti. Évalué à 5. Dernière modification le 03 octobre 2012 à 20:29.
Itérer sur les caractères est une opération triviale et, dans ce cas, c'est la boucle d'évaluation de CPython qui sera le facteur dominant.
Par contre, là où ça peut être plus lent, c'est dans certaines créations de chaînes en combinant des chaînes utilisant des représentations différentes (par exemple : une concaténation, ou bien un appel à la méthode str.replace()). Cela ne se remarquera vraiment que sur des chaînes très longues, donc pas les cas les plus courants.
(en contrepartie, il y a aussi certaines opérations qui deviennent plus rapides, par exemple décoder en utf-8 une chaîne d'octets qui s'avérerait être purement ASCII : ce cas est optimisé comme un simple memcpy())