Pourquoi N'y a-t-il pas de fonction xrange dans Python3?

Certaines mesures de performance, à l'aide de timeit au lieu d'essayer de le faire manuellement avec time .

tout d'Abord, Apple 2.7.2 64 bits:

In [37]: %timeit collections.deque((x for x in xrange(10000000) if x%4 == 0), maxlen=0)
1 loops, best of 3: 1.05 s per loop

Maintenant, python.org 3.3.0 64 bits:

In [83]: %timeit collections.deque((x for x in range(10000000) if x%4 == 0), maxlen=0)
1 loops, best of 3: 1.32 s per loop

In [84]: %timeit collections.deque((x for x in xrange(10000000) if x%4 == 0), maxlen=0)
1 loops, best of 3: 1.31 s per loop

In [85]: %timeit collections.deque((x for x in iter(range(10000000)) if x%4 == 0), maxlen=0) 
1 loops, best of 3: 1.33 s per loop

apparemment, 3.x range est vraiment un peu plus lent que 2.x xrange . Et la fonction xrange de L'OP n'a rien à voir avec ça. (Pas surprenant, comme un appel unique à la fente __iter__ n'est pas susceptible d'être visible parmi 10000000 appels à tout ce qui se passe dans la boucle, mais quelqu'un a évoqué cette possibilité.)

mais c'est seulement 30% plus lent. Comment l'opération a-t-elle été aussi lente? Si je répète les mêmes tests avec Python 32 bits, j'obtiens 1,58 contre 3,12. Donc je suppose que c'est encore un autre de ces cas où 3.x a été optimisé pour une performance 64 bits de manière à nuire à 32 bits.

Mais est-ce vraiment important? Check this out, avec 3.3.0 64 bits de nouveau:

In [86]: %timeit [x for x in range(10000000) if x%4 == 0]
1 loops, best of 3: 3.65 s per loop

ainsi, la construction du list prend plus de deux fois plus de temps que l'itération entière.

et quant à" consomme beaucoup plus de ressources que Python 2.6+", de mes tests, il ressemble à un 3.x range est exactement la même taille qu'un 2.x xrange -et, même s'il était 10x aussi grand, la construction de la liste inutile est toujours environ 10000000x plus d'un problème que tout ce que l'itération de gamme pourrait faire.

et qu'en est-il d'une boucle explicite for au lieu de la boucle C à l'intérieur de deque ?

In [87]: def consume(x):
   ....:     for i in x:
   ....:         pass
In [88]: %timeit consume(x for x in range(10000000) if x%4 == 0)
1 loops, best of 3: 1.85 s per loop

donc, presque autant de temps perdu dans l'énoncé for que dans le travail réel d'itération du range .

si vous craignez d'optimiser l'itération d'un objet range, vous cherchez probablement au mauvais endroit.

en attendant, vous continuez de vous demander pourquoi xrange a été supprimé, peu importe le nombre de fois où les gens vous disent la même chose, mais je vais le répéter encore: il n'a pas été supprimé: il a été renommé en range , et le 2.x range est ce qui a été supprimé.

Voici une preuve que l'objet 3.3 range est un descendant direct du 2.x xrange objet (et non du 2.x range fonction): la source à 3.3 range et 2.7 xrange . Vous pouvez même voir le changer l'historique (lié, je crois, au changement qui a remplacé la dernière instance de la chaîne" xrange " n'importe où dans le fichier).

alors, pourquoi est-ce plus lent?

Eh bien, pour commencer, ils ont ajouté beaucoup de nouvelles fonctionnalités. Pour un autre, ils ont fait toutes sortes de changements partout (en particulier à l'intérieur de l'itération) qui ont des effets secondaires mineurs. Et il y avait eu beaucoup de travail à optimiser de façon spectaculaire divers cas importants, même s'il pessimise parfois légèrement les cas moins importants. Ajoutez tout cela, et je ne suis pas surpris que itérer un range aussi vite que possible soit maintenant un peu plus lent. C'est une de ces affaires moins importantes sur laquelle personne ne se soucierait assez pour se concentrer. Personne n'est susceptible d'avoir jamais un cas d'utilisation réelle où cette différence de performance est le point chaud dans leur code.