qu'est-ce qui est plus rapide, une test = ou un != ?

bonjour,

en cherchant à optimiser des traitements itératifs longs et remplis de if a==b, je me suis rendus compte que ce qui importait dans mon code était plutôt que a!=b

je me demande du coup la question de la performance, rapidité.

qu'est-ce qui va plus vite à faire :

Code:

---

1 2 3 4

if a==b: traitement1 else: traitement2

---

ou

Code:

---

1 2 3 4

if a!=b: traitement2 else: traitement1

---

Sachant que j'ai 9 chances sur 10 qu'il y ait une égalité avec mes jeux de données.

Mes variables a et b sont des chaines très longues, donc je suppose que python arrête la comparaison dès que l'un des caractères parcouru est différent non ?
donc je me dis que mon code ira plus vite en testant la différence plutôt qu'en testant l'égalité.

je m'expliquer,
si a="eeeeeeeeeeeeeeeeeeeeeee"
si b="eXeeeeeeeeeeeeeeeeeeeee"

quand je cherche l'égalité, je suppose que python teste a[0] avec b[0], puis a[1] avec b[1].... mais au niveau x[1] des chaines il ya déjà une différence, est-ce que python teste quand-même l'intégralité de la chaine avant de continuer le process ?

qu'en pensez-vous ?

si 9 fois sur 10 a égale b, alors 9 fois sur 10 la chaîne sera entièrement parcourue quel que soit le test ...
pour le 1 fois sur 10 restant, tester != sera plus rapide amha ...

donc il vaut mieux faire if a != b

Salut,

Citation:

---

Mes variables a et b sont des chaines très longues, donc je suppose que python arrête la comparaison dès que l'un des caractères parcouru est différent non ?

---

Ca dépend :?

Les str étant des objets "non mutables", on peut essayer d'exploiter l'identité. ou le fait que stocker dans deux emplacements des objets "identiques" n'est que gaspillage de "place".

Par défaut, çà ne fonctionne pas toujours:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

>>> a = 'abc' >>> b = 'abc' >>> a is b True >>> a == b True >>> b = ''.join(list(a)) >>> a is b False >>> a == b True

---

L'interprêteur fait ce qu'il peut... Mais on peut l'aider un peu en poussant le str dans une la table globale des str dites "interned" - une hash table quoi.
Appliqué à l'exemple précédent:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

>>> import sys >>> a = sys.intern('abc') >>> b = sys.intern('abc') >>> a is b True >>> a == b True >>> b = sys.intern(''.join(list(a))) >>> a is b True >>> a == b True >>>

---

=> On assigne à chaque "str" qui vous intéresse un identifiant qui sera différent si les "str" sont différentes... Ce qui va nous permettre d'utiliser l'identité plutôt que l'égalité. Et côté performance, y a pas photo.

- W

Bonjour,

Je profite de la discussion pour rajouter 2 questions:

1/ Est il possible d'automatiser le sys.intern sur toutes les chaînes crées dans un module ?

2/ Est-il possible de profiler les différentes utilisations des strings ? La seule granularité que j'obtiens c'est une ligne "module string -> durée", qui a l'air de rassembler les opérations de créations mais aussi de concaténation (+) et de comparaison (==) de strings

Merci d'avance

Bonjour,

Citation:

---

1/ Est il possible d'automatiser le sys.intern sur toutes les chaînes crées dans un module ?

---

Avez-vous essayé? ;)

La particularité de coder, n'est-elle pas celle d'automatiser les choses?

Citation:

---

2/ Est-il possible de profiler les différentes utilisations des strings ? La seule granularité que j'obtiens c'est une ligne "module string -> durée", qui a l'air de rassembler les opérations de créations mais aussi de concaténation (+) et de comparaison (==) de strings

---

Je ne comprend pas où vous voulez en venir, peut-être avec un exemple ou un code, je comprendrais mieux votre question. :oops:

Bonjour Fred, et merci

Je n'ai pas python sous la main donc désolé si je manque de précision. J'en donnerai plus ce soir, mais:

1/ J'imagine décorer le constructeur du module string, mais je n'ai pas encore regardé la constitution de ce module. J'imagine qu'il faut traiter les divers formats (unicode etc), qu'il y a peut être une factory à décorer ...

2/ C'est justement pour éviter de décorer tous les modules que je préférerais savoir grâce à un profiler ou cela vaut le coup d'utiliser sys.intern.

Malheureusement, cProfile agrège les timers de toutes les opérations sur les strings, ce qui ne permettra pas de savoir si c'est la comparaison de strings qui fait perdre du temps, ou une autre opération.