Discussion :

[wiztricks]

Salut,

Pour être honnête, le "égal" et "in" sont quasiment équivalents.

Déjà çà mesure le temps mis pour exécuter toute la fonction et ce qu'on cherche à mesurer (le test de casse) s'exécutera autant de fois qu'il y a de caractères dans la chaîne passées en argument.

Avec 4 caractères, si on noie le pouième qu'on cherche à mesurer dans l'overhead , il n'est pas anormal de trouver des temps semblables.

- W

[Beginner.]

Salut,

Pour être honnête, le "égal" et "in" sont quasiment équivalents. Parfois c'est le "égal" qui devance, parfois c'est le "in". Mais le regex lui est carrément à la rue *10. C'est compréhensible, c'est un truc énorme le regex (mais peut-être j'ai pas pris la bonne méthode)...

Merci pour le test. Oui effectivement avec la regex c'est beaucoup plus long mais il y a peut-être des fonctions plus rapides, certaines fonctions font peut-être plus de choses (comme fournir les positions des éléments trouvés) que juste chercher ce qui expliquerait en partie qu'elles soient plus longues...

Enfin je ne connais pas les fonctions python je parle en général par rapport à d'autres langages.

Et aussi apparemment pour la regex, tu as utilisé une chaine de caractère mais je me demande si ce ne serait pas plus rapide avec un intervalle : [a-z]. La regex c'est une boite noire mais on peut penser que ce serait optimisé dans ce cas c'est-à-dire que cela se rapprocherait de la double comparaisons puisque là aussi on a les deux extrémités d'un intervalle.

Je vois parfois qu'on peut compiler une regex, peut-être que c'est plus rapide une fois compilé ?

Il ne s'agit pour le processeur que de 2 tests d'égalité. L'opération "in" implique fatalement une boucle. Dans ce cas précis la boucle ne concerne que 26 éléments donc elle peut être rapide mais si on prend un cas plus général...

Oui il doit y avoir une boucle quelque part et du coup cela complique l'analyse car je suppose que la rapidité de la double comparaison doit être la même quelque soit la lettre testée alors qu'avec le in cela dépendra de la lettre : le plus rapide pour la lettre a et le plus lent pour la lettre z.

[Pyramidev]

Je vois parfois qu'on peut compiler une regex, peut-être que c'est plus rapide une fois compilé ?

C'est une bonne remarque. Indépendamment du langage, quand une même expression régulière est utilisée plusieurs fois, il vaut mieux la compiler une seule fois.

Comment Python gère-t-il la compilation des expression régulières ? Pour ceux que ça intéresse, il faut regarder le code source.
En haut de la documentation du module re, il y a un lien vers le code source du module.

La fonction re.search est définie ici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
def search(pattern, string, flags=0):
    """Scan through string looking for a match to the pattern, returning
    a Match object, or None if no match was found."""
    return _compile(pattern, flags).search(string)

_compile équivaut à re.compile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def compile(pattern, flags=0):
    "Compile a regular expression pattern, returning a Pattern object."
    return _compile(pattern, flags)

Quand une même expression régulière est utilisée plusieurs fois, il vaut mieux appeler une seule fois re.compile.
Par exemple, de mon côté, quand une expression régulière est statiquement connue, je la compile au moment de l'import avec re.compile et je mets le résultat dans une variable globale.

Cela dit, en pratique, si on regarde le code source de _compile, on voit qu'il y a de la mémoïsation : jusqu'à 512 résultats de _compile sont gardés en mémoire, les plus récents étant prioritaires sur les plus anciens. Du coup, en vrai, si on appelle re.search en boucle avec la même expression régulière, même si la fonction _compile sera appelée inutilement en boucle, l'expression régulière ne sera pas compilée en boucle.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
_cache = {}  # ordered!
 
_MAXCACHE = 512
def _compile(pattern, flags):
    # internal: compile pattern
    if isinstance(flags, RegexFlag):
        flags = flags.value
    try:
        return _cache[type(pattern), pattern, flags]
    except KeyError:
        pass
    if isinstance(pattern, Pattern):
        if flags:
            raise ValueError(
                "cannot process flags argument with a compiled pattern")
        return pattern
    if not sre_compile.isstring(pattern):
        raise TypeError("first argument must be string or compiled pattern")
    p = sre_compile.compile(pattern, flags)
    if not (flags & DEBUG):
        if len(_cache) >= _MAXCACHE:
            # Drop the oldest item
            try:
                del _cache[next(iter(_cache))]
            except (StopIteration, RuntimeError, KeyError):
                pass
        _cache[type(pattern), pattern, flags] = p
    return p

[Beginner.]

Merci.

Comment Python gère-t-il la compilation des expression régulières ? Pour ceux que ça intéresse, il faut regarder le code source.
En haut de la documentation du module re, il y a un lien vers le code source du module.

Ah je ne savais pas qu'il y avait le code source...

Mais du coup je me demande si il existe des outils qui permettent de voir comment telle ou telle regex est exécutée. C'est-à-dire est-il possible de connaitre l'algorithme correspondant à une regex ? Cela permettrait de savoir comment optimiser l'écriture de notre regex.

Exemple concret, je me demande si il y a une différence entre [a-z] et [abcdefghijklmnopqrstuvwxyz] ? Ou entre [0-9] et [0123456789] ?

[Arioch]

Un site comme regex101 permet de tester ses expressions régulières et de les optimiser.

[Sve@r]

Et aussi apparemment pour la regex, tu as utilisé une chaine de caractère mais je me demande si ce ne serait pas plus rapide avec un intervalle : [a-z]. La regex c'est une boite noire mais on peut penser que ce serait optimisé dans ce cas c'est-à-dire que cela se rapprocherait de la double comparaisons puisque là aussi on a les deux extrémités d'un intervalle.

Je vois parfois qu'on peut compiler une regex, peut-être que c'est plus rapide une fois compilé ?

Ok, en avant pour la compilation
Petite modification du code donc...

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
comp=re.compile("[a-z]")
def fct_re(l):
	for x in l: comp.search(x)

Résultat: on gagne un *2 par rapport aux premiers tests mais ça reste quand-même plus long *5 par rapport aux tests simples.

Oui il doit y avoir une boucle quelque part et du coup cela complique l'analyse car je suppose que la rapidité de la double comparaison doit être la même quelque soit la lettre testée alors qu'avec le in cela dépendra de la lettre : le plus rapide pour la lettre a et le plus lent pour la lettre z.

Sans oublier quand la lettre n'y est pas (ie "0" dans mon test)...

Un site comme regex101 permet de tester ses expressions régulières et de les optimiser.

Joli lui je le mets dans mes favoris

[Beginner.]

Ok, en avant pour la compilation
Petite modification du code donc...

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
comp=re.compile("[a-z]")
def fct_re(l):
    for x in l: comp.search(x)

Résultat: on gagne un *2 par rapport aux premiers tests mais ça reste quand-même plus long *5 par rapport aux tests simples.

Ah quand même c'est un bon gain... Mais c'est vrai ça reste mauvais comparé aux autres méthodes...

Du coup je commence à me demander si la méthode sans les regex est plus performante même dans les autres types de recherche...

J'ai vu qu'il y avait des choses pour optimiser mais bon...

[Sve@r]

Du coup je commence à me demander si la méthode sans les regex est plus performante même dans les autres types de recherche...

Ah personnellement la regex je ne m'en sers que si je ne peux pas faire autrement. Une recherche sur une string un peu exotique ou une substitution un peu complexe ok mais si la chaine à filtrer est une simple chaine lambda...

[CosmoKnacki]

Attention avec la comparaison letter.upper() == letter.lower() pour déterminer si un caractère est une lettre ou pas. Si on prend l'eszett allemand, la version minuscule est ß, mais la version majuscule est soit ẞ, soit SS. Or si on teste le changement de casse sur la version minuscule, on obtient (Python 3.6.9):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
>>> 'ß'.upper()
'SS'
>>> 'ß'.lower()
'ß'
>>> 'ß'.upper() == 'ß'.lower()
False

D'autre part, il existe des lettres n'ayant pas de version majuscule ou de version minuscule.

https://www.unicode.org/reports/tr21/tr21-5.html

[Christianbash]

Bonjour,
Je suis etudiant et nous avons un cours de python, j'avoue que j'y vois du noir est ce que quelqu'un peut m'assister?

[Beginner.]

Bonjour,
Je suis etudiant et nous avons un cours de python, j'avoue que j'y vois du noir est ce que quelqu'un peut m'assister?

Ben ouvre un ou plusieurs fil pour poser tes questions... Parce qu'ici tu seras hors-sujet...