En gros : copier N caractères ASCII (stockés dans le format "UCS-1") nécessite de copier N octets, alors que copier N caractères stockés dans le format UCS-4 (Python 3.2 sous Linux) nécessite de copier 4*N octets. Par exemple, str[a:b] copie des caractères. Et comme l'a écrit Antoine : encoder une chaîne Unicode "de type ASCII" en UTF-8 revient simplement à faire un "memcpy" (en gros), ce qui est ultra rapide (comparé à l'encodeur de Python 2.7 et 3.2).
Côté négatif : les opérations manipulant des chaînes utilisant différents formats nécessitent de convertir les chaînes vers le même format. Par exemple, "10€".replace("", " ") nécessite de convertir "_" du format UCS-1 au format UCS-2. Idem pour "10 " + "€".
Créer une chaîne de caractère nécessite de connaître le caractère "maximum" (code Unicode le plus grand), ce qui nécessite de lire l'ensemble des caractères de la chaîne. Cette opération est coûteuse.
Le bilan est mitigé car certaines opérations sont plus lentes, mais d'un autre, certaines fonctions ont été optimisées. Dans le meilleur des cas, certaines opérations Unicode avec Python 3.3 sont désormais plus rapides que ces opérations sur des octets avec Python 2.7 !
Je ne connais pas de benchmark "global". Il existe divers micro-benchmarks qui ne sont pas représentatifs. En tout cas, il est sûr que la consommation mémoire est bien meilleure !
[^] # Re: strings: Optimisation mémoire vs cpu?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.3 est sorti. Évalué à 7.
L'optimisation en occupation mémoire des chaînes de caractères n'a-t-elle pas un impact en performance cpu?
Côté positif : certaines opérations sont beaucoup plus rapide, notamment quand on manipule des chaînes de caractère "ASCII" :
http://docs.python.org/dev/whatsnew/3.3.html#optimizations
En gros : copier N caractères ASCII (stockés dans le format "UCS-1") nécessite de copier N octets, alors que copier N caractères stockés dans le format UCS-4 (Python 3.2 sous Linux) nécessite de copier 4*N octets. Par exemple, str[a:b] copie des caractères. Et comme l'a écrit Antoine : encoder une chaîne Unicode "de type ASCII" en UTF-8 revient simplement à faire un "memcpy" (en gros), ce qui est ultra rapide (comparé à l'encodeur de Python 2.7 et 3.2).
Côté négatif : les opérations manipulant des chaînes utilisant différents formats nécessitent de convertir les chaînes vers le même format. Par exemple, "10€".replace("", " ") nécessite de convertir "_" du format UCS-1 au format UCS-2. Idem pour "10 " + "€".
Créer une chaîne de caractère nécessite de connaître le caractère "maximum" (code Unicode le plus grand), ce qui nécessite de lire l'ensemble des caractères de la chaîne. Cette opération est coûteuse.
Le bilan est mitigé car certaines opérations sont plus lentes, mais d'un autre, certaines fonctions ont été optimisées. Dans le meilleur des cas, certaines opérations Unicode avec Python 3.3 sont désormais plus rapides que ces opérations sur des octets avec Python 2.7 !
Je ne connais pas de benchmark "global". Il existe divers micro-benchmarks qui ne sont pas représentatifs. En tout cas, il est sûr que la consommation mémoire est bien meilleure !