Pourquoi «1000000000000000 à portée (1000000000000001)» est-il si rapide en Python 3?

Je crois comprendre que la range()fonction, qui est en fait un type d'objet en Python 3 , génère son contenu à la volée, semblable à un générateur.

Cela étant le cas, je m'attendais à ce que la ligne suivante prenne un temps excessif, car pour déterminer si 1 quadrillion est dans la plage, il faudrait générer un quadrillion de valeurs:

1000000000000000 in range(1000000000000001)

De plus: il semble que peu importe le nombre de zéros que j'ajoute, le calcul prend plus ou moins le même temps (essentiellement instantané).

J'ai également essayé des choses comme ça, mais le calcul est encore presque instantané:

1000000000000000000000 in range(0,1000000000000000000001,10) # count by tens

Si j'essaie d'implémenter ma propre fonction de plage, le résultat n'est pas si agréable !!

def my_crappy_range(N):
    i = 0
    while i < N:
        yield i
        i += 1
    return

Que fait l' range()objet sous le capot qui le rend si rapide?

La réponse de Martijn Pieters a été choisie pour son exhaustivité, mais voir également la première réponse d'Abarnert pour une bonne discussion de ce que cela signifie pour rangeêtre une séquence à part entière dans Python 3, et quelques informations / avertissements concernant l'incohérence potentielle pour __contains__l'optimisation des fonctions dans les implémentations Python . L'autre réponse d'abarnert va plus en détail et fournit des liens pour ceux qui s'intéressent à l'histoire derrière l'optimisation dans Python 3 (et le manque d'optimisation de xrangedans Python 2). Les réponses par poke et par wim fournissent le code source C pertinent et des explications pour ceux qui sont intéressés.

L' range()objet Python 3 ne produit pas de nombres immédiatement; c'est un objet de séquence intelligent qui produit des nombres à la demande . Il ne contient que vos valeurs de début, d'arrêt et de pas, puis lorsque vous parcourez l'objet, l'entier suivant est calculé à chaque itération.

L'objet implémente également le object.__contains__crochet et calcule si votre numéro fait partie de sa plage. Le calcul est une opération à temps constant (presque) ^* . Il n'est jamais nécessaire de parcourir tous les entiers possibles de la plage.

De la range()documentation de l' objet :

L'avantage du rangeécrasez régulièrement listou tupleest qu'un objet de gamme aura toujours la même (petite) quantité de mémoire, peu importe la taille de la plage qu'elle représente (car il ne stocke que les start, stopet les stepvaleurs, le calcul des éléments individuels et les sous - domaines comme requis).

Donc, au minimum, votre range()objet ferait:

class my_range(object):
    def __init__(self, start, stop=None, step=1):
        if stop is None:
            start, stop = 0, start
        self.start, self.stop, self.step = start, stop, step
        if step < 0:
            lo, hi, step = stop, start, -step
        else:
            lo, hi = start, stop
        self.length = 0 if lo > hi else ((hi - lo - 1) // step) + 1

    def __iter__(self):
        current = self.start
        if self.step < 0:
            while current > self.stop:
                yield current
                current += self.step
        else:
            while current < self.stop:
                yield current
                current += self.step

    def __len__(self):
        return self.length

    def __getitem__(self, i):
        if i < 0:
            i += self.length
        if 0 <= i < self.length:
            return self.start + i * self.step
        raise IndexError('Index out of range: {}'.format(i))

    def __contains__(self, num):
        if self.step < 0:
            if not (self.stop < num <= self.start):
                return False
        else:
            if not (self.start <= num < self.stop):
                return False
        return (num - self.start) % self.step == 0

Il manque encore plusieurs éléments pris en charge par un réel range()(tels que les méthodes .index()ou .count(), le hachage, les tests d'égalité ou le découpage), mais devraient vous donner une idée.

J'ai également simplifié l' __contains__implémentation pour me concentrer uniquement sur les tests entiers; si vous donnez à un range()objet réel une valeur non entière (y compris les sous-classes de int), un balayage lent est lancé pour voir s'il existe une correspondance, tout comme si vous utilisez un test de confinement par rapport à une liste de toutes les valeurs contenues. Cela a été fait pour continuer à prendre en charge d'autres types numériques qui se trouvent juste à prendre en charge les tests d'égalité avec des entiers, mais qui ne devraient pas également prendre en charge l'arithmétique des entiers. Voir le problème Python d' origine qui implémentait le test de confinement.

* Temps presque constant car les entiers Python sont illimités et donc les opérations mathématiques augmentent également dans le temps à mesure que N croît, ce qui en fait une opération O (log N). Comme tout est exécuté dans du code C optimisé et que Python stocke les valeurs entières dans des morceaux de 30 bits, vous manquerez de mémoire avant de voir un impact sur les performances en raison de la taille des entiers impliqués ici.

Le malentendu fondamental ici est de penser que rangec'est un générateur. Ce n'est pas. En fait, ce n'est pas une sorte d'itérateur.

Vous pouvez le dire assez facilement:

>>> a = range(5)
>>> print(list(a))
[0, 1, 2, 3, 4]
>>> print(list(a))
[0, 1, 2, 3, 4]

S'il s'agissait d'un générateur, l'itérer une fois l'épuiserait:

>>> b = my_crappy_range(5)
>>> print(list(b))
[0, 1, 2, 3, 4]
>>> print(list(b))
[]

En rangeréalité, c'est une séquence, tout comme une liste. Vous pouvez même tester ceci:

>>> import collections.abc
>>> isinstance(a, collections.abc.Sequence)
True

Cela signifie qu'il doit suivre toutes les règles d'une séquence:

>>> a[3]         # indexable
3
>>> len(a)       # sized
5
>>> 3 in a       # membership
True
>>> reversed(a)  # reversible
<range_iterator at 0x101cd2360>
>>> a.index(3)   # implements 'index'
3
>>> a.count(3)   # implements 'count'
1

La différence entre a rangeet a listest que a rangeest une séquence paresseuse ou dynamique ; il ne se rappelle pas toutes ses valeurs, il vient se souvient de son start, stopet step, et crée les valeurs à la demande sur __getitem__.

(Comme une note de côté, si vous print(iter(a)), vous remarquerez que les rangeutilisations du même listiteratortype que list. Comment ça marche? A listiteratorne pas utiliser quoi que ce soit de spécial , listsauf pour le fait qu'il fournit une implémentation C __getitem__, il fonctionne très bien pour rangeaussi.)

Maintenant, rien ne dit que le temps Sequence.__contains__doit être constant - en fait, pour des exemples évidents de séquences comme list, ce n'est pas le cas. Mais rien ne dit que cela ne peut pas être. Et il est plus facile à implémenter range.__contains__de simplement le vérifier mathématiquement ( (val - start) % step, mais avec une complexité supplémentaire pour gérer les étapes négatives) que de générer et de tester réellement toutes les valeurs, alors pourquoi ne le ferait-il pas mieux?

Mais il ne semble pas y avoir quoi que ce soit dans la langue qui garantisse que cela se produira. Comme le souligne Ashwini Chaudhari, si vous lui donnez une valeur non intégrale, au lieu de la convertir en entier et de faire le test mathématique, cela reviendra à itérer toutes les valeurs et à les comparer une par une. Et juste parce que les versions CPython 3.2+ et PyPy 3.x contiennent cette optimisation, et c'est une bonne idée évidente et facile à faire, il n'y a aucune raison pour qu'IronPython ou NewKickAssPython 3.x ne puissent pas le laisser de côté. (Et en fait, CPython 3.0-3.1 ne l'a pas inclus.)

Si en rangefait, c'était un générateur, my_crappy_rangealors ça n'aurait pas de sens de tester de __contains__cette façon, ou du moins la façon dont ça aurait du sens ne serait pas évidente. Si vous avez déjà répété les 3 premières valeurs, est-ce 1toujours inle générateur? Le test doit- 1il le faire itérer et consommer toutes les valeurs jusqu'à 1(ou jusqu'à la première valeur >= 1)?

Utilisez la source , Luke!

En CPython, range(...).__contains__(un wrapper de méthode) finira par déléguer à un calcul simple qui vérifie si la valeur peut éventuellement être dans la plage. La raison de la vitesse ici est que nous utilisons un raisonnement mathématique sur les limites, plutôt qu'une itération directe de l'objet plage . Pour expliquer la logique utilisée:

1. Vérifiez que le nombre est compris entre startet stop, et
2. Vérifiez que la valeur de pas ne dépasse pas notre nombre.

Par exemple, 994c'est range(4, 1000, 2)parce que:

1. 4 <= 994 < 1000, et
2. (994 - 4) % 2 == 0.

Le code C complet est inclus ci-dessous, ce qui est un peu plus détaillé à cause de la gestion de la mémoire et des détails de comptage des références, mais l'idée de base est là:

static int
range_contains_long(rangeobject *r, PyObject *ob)
{
    int cmp1, cmp2, cmp3;
    PyObject *tmp1 = NULL;
    PyObject *tmp2 = NULL;
    PyObject *zero = NULL;
    int result = -1;

    zero = PyLong_FromLong(0);
    if (zero == NULL) /* MemoryError in int(0) */
        goto end;

    /* Check if the value can possibly be in the range. */

    cmp1 = PyObject_RichCompareBool(r->step, zero, Py_GT);
    if (cmp1 == -1)
        goto end;
    if (cmp1 == 1) { /* positive steps: start <= ob < stop */
        cmp2 = PyObject_RichCompareBool(r->start, ob, Py_LE);
        cmp3 = PyObject_RichCompareBool(ob, r->stop, Py_LT);
    }
    else { /* negative steps: stop < ob <= start */
        cmp2 = PyObject_RichCompareBool(ob, r->start, Py_LE);
        cmp3 = PyObject_RichCompareBool(r->stop, ob, Py_LT);
    }

    if (cmp2 == -1 || cmp3 == -1) /* TypeError */
        goto end;
    if (cmp2 == 0 || cmp3 == 0) { /* ob outside of range */
        result = 0;
        goto end;
    }

    /* Check that the stride does not invalidate ob's membership. */
    tmp1 = PyNumber_Subtract(ob, r->start);
    if (tmp1 == NULL)
        goto end;
    tmp2 = PyNumber_Remainder(tmp1, r->step);
    if (tmp2 == NULL)
        goto end;
    /* result = ((int(ob) - start) % step) == 0 */
    result = PyObject_RichCompareBool(tmp2, zero, Py_EQ);
  end:
    Py_XDECREF(tmp1);
    Py_XDECREF(tmp2);
    Py_XDECREF(zero);
    return result;
}

static int
range_contains(rangeobject *r, PyObject *ob)
{
    if (PyLong_CheckExact(ob) || PyBool_Check(ob))
        return range_contains_long(r, ob);

    return (int)_PySequence_IterSearch((PyObject*)r, ob,
                                       PY_ITERSEARCH_CONTAINS);
}

La "viande" de l'idée est mentionnée dans la ligne :

/* result = ((int(ob) - start) % step) == 0 */ 

Pour terminer, regardez la range_containsfonction en bas de l'extrait de code. Si la vérification de type exacte échoue, nous n'utilisons pas l'algorithme intelligent décrit, mais nous retombons à une recherche d'itération stupide de la plage en utilisant _PySequence_IterSearch! Vous pouvez vérifier ce comportement dans l'interpréteur (j'utilise ici la v3.5.0):

>>> x, r = 1000000000000000, range(1000000000000001)
>>> class MyInt(int):
...     pass
... 
>>> x_ = MyInt(x)
>>> x in r  # calculates immediately :) 
True
>>> x_ in r  # iterates for ages.. :( 
^\Quit (core dumped)

Pour ajouter à la réponse de Martijn, ceci est la partie pertinente de la source (en C, car l'objet range est écrit en code natif):

static int
range_contains(rangeobject *r, PyObject *ob)
{
    if (PyLong_CheckExact(ob) || PyBool_Check(ob))
        return range_contains_long(r, ob);

    return (int)_PySequence_IterSearch((PyObject*)r, ob,
                                       PY_ITERSEARCH_CONTAINS);
}

Donc, pour les PyLongobjets (qui est inten Python 3), il utilisera la range_contains_longfonction pour déterminer le résultat. Et cette fonction vérifie essentiellement si se obtrouve dans la plage spécifiée (bien qu'elle semble un peu plus complexe en C).

S'il ne s'agit pas d'un intobjet, il revient à l'itération jusqu'à ce qu'il trouve la valeur (ou non).

Toute la logique pourrait être traduite en pseudo-Python comme ceci:

def range_contains (rangeObj, obj):
    if isinstance(obj, int):
        return range_contains_long(rangeObj, obj)

    # default logic by iterating
    return any(obj == x for x in rangeObj)

def range_contains_long (r, num):
    if r.step > 0:
        # positive step: r.start <= num < r.stop
        cmp2 = r.start <= num
        cmp3 = num < r.stop
    else:
        # negative step: r.start >= num > r.stop
        cmp2 = num <= r.start
        cmp3 = r.stop < num

    # outside of the range boundaries
    if not cmp2 or not cmp3:
        return False

    # num must be on a valid step inside the boundaries
    return (num - r.start) % r.step == 0

Si vous vous demandez pourquoi cette optimisation a été ajoutée range.__contains__et pourquoi elle n'a pas été ajoutée xrange.__contains__en 2.7:

Tout d'abord, comme Ashwini Chaudhary l'a découvert, le problème 1766304 a été ouvert explicitement pour être optimisé [x]range.__contains__. Un correctif a été accepté et archivé pour la version 3.2 , mais il n'a pas été rétroporté vers la version 2.7 car "xrange s'est comporté comme ça depuis si longtemps que je ne vois pas ce qu'il nous achète pour valider le correctif si tard." (2.7 était presque sorti à ce moment-là.)

Pendant ce temps:

À l'origine, xrangeétait un objet pas tout à fait séquence. Comme le disent les documents 3.1 :

Les objets de plage ont très peu de comportement: ils ne prennent en charge que l'indexation, l'itération et la lenfonction.

Ce n'était pas tout à fait vrai; un xrangeobjet a en fait pris en charge quelques autres choses qui viennent automatiquement avec l'indexation et len, ^* y compris __contains__(via la recherche linéaire). Mais personne ne pensait qu'il valait la peine d'en faire des séquences complètes à l'époque.

Ensuite, dans le cadre de la mise en œuvre du PEP des classes de base abstraites , il était important de déterminer quels types intégrés devraient être marqués comme implémentant quels ABC et xrange/ ou rangeprétendaient implémenter collections.Sequence, même s'il ne traitait toujours que le même "très petit comportement". Personne n'a remarqué ce problème jusqu'au numéro 9213 . Le patch pour cette question non seulement ajouté indexet countà 3,2 de range, il a également retravaillé l'optimisation __contains__(qui partage le même calcul avec index, et est directement utilisé par count). ^** Cette modification est également entrée dans la version 3.2 et n'a pas été rétroportée vers 2.x, car "c'est un correctif qui ajoute de nouvelles méthodes". (À ce stade, 2.7 avait déjà dépassé le statut rc.)

Il y avait donc deux chances d'obtenir cette optimisation rétroportée à 2,7, mais elles ont toutes deux été rejetées.

_{* En fait, vous obtenez même l'itération gratuitement avec l'indexation seule, mais dans 2.3 les xrange objets ont un itérateur personnalisé.}

_{** La première version l'a en fait réimplémentée et s'est trompée de détails — par exemple, elle vous donnerait MyIntSubclass(2) in range(5) == False. Mais la version mise à jour de Daniel Stutzbach du correctif a restauré la plupart du code précédent, y compris le retour au générique, lent _PySequence_IterSearchque la version antérieure à 3.2 range.__contains__utilisait implicitement lorsque l'optimisation ne s'appliquait pas.}

Les autres réponses l'ont déjà bien expliqué, mais je voudrais proposer une autre expérience illustrant la nature des objets de la gamme:

>>> r = range(5)
>>> for i in r:
        print(i, 2 in r, list(r))

0 True [0, 1, 2, 3, 4]
1 True [0, 1, 2, 3, 4]
2 True [0, 1, 2, 3, 4]
3 True [0, 1, 2, 3, 4]
4 True [0, 1, 2, 3, 4]

Comme vous pouvez le voir, un objet de plage est un objet qui se souvient de sa plage et peut être utilisé plusieurs fois (même en itérant dessus), pas seulement un générateur ponctuel.

Il s'agit d'une approche paresseuse de l'évaluation et d'une optimisation supplémentaire derange . Les valeurs dans les plages n'ont pas besoin d'être calculées avant une utilisation réelle, ou même davantage en raison d'une optimisation supplémentaire.

Soit dit en passant, votre entier n'est pas si grand, considérez sys.maxsize

sys.maxsize in range(sys.maxsize) est assez rapide

en raison de l'optimisation - il est facile de comparer un entier donné uniquement avec le min et le max de la plage.

mais:

Decimal(sys.maxsize) in range(sys.maxsize) est assez lent .

(dans ce cas, il n'y a pas d'optimisation dans range, donc si python reçoit Decimal inattendu, python comparera tous les nombres)

Vous devez être au courant d'un détail d'implémentation, mais vous ne devez pas vous y fier, car cela pourrait changer à l'avenir.

TL; DR

L'objet retourné par range()est en fait unrange objet. Cet objet implémente l'interface de l'itérateur afin que vous puissiez parcourir ses valeurs séquentiellement, tout comme un générateur, une liste ou un tuple.

Mais il implémente également l' __contains__interface qui est en fait ce qui est appelé lorsqu'un objet apparaît sur le côté droit de l' inopérateur. La __contains__()méthode renvoie un boolélément indiquant si l'élément du côté gauche de inl'objet se trouve ou non dans l'objet. Puisque les rangeobjets connaissent leurs limites et leur foulée, c'est très facile à implémenter dans O (1).

1. En raison de l'optimisation, il est très facile de comparer des entiers donnés uniquement avec la plage min et max.
2. La raison pour laquelle la fonction range () est si rapide en Python3 est que nous utilisons ici un raisonnement mathématique pour les limites, plutôt qu'une itération directe de l'objet range.
3. Donc, pour expliquer la logique ici:
   • Vérifiez si le nombre se situe entre le début et l'arrêt.
   • Vérifiez si la valeur de précision de pas ne dépasse pas notre nombre.

4. Prenons un exemple, 997 est dans la plage (4, 1000, 3) parce que:

   4 <= 997 < 1000, and (997 - 4) % 3 == 0.

Essayez x-1 in (i for i in range(x))de grandes xvaleurs, qui utilisent une compréhension du générateur pour éviter d'appeler l' range.__contains__optimisation.