Sont liste-des compréhensions et fonctionnelle des fonctions plus rapide que “pour les boucles”?

Les éléments suivants sont des lignes directrices et des suppositions éclairées, fondées sur l'expérience. Vous devriez timeit ou le profil de votre cas concret d'utilisation pour obtenir des chiffres précis, et ces chiffres peuvent parfois être en désaccord avec le ci-dessous.

Une compréhension de liste est généralement un tout petit peu plus rapide que précisément l'équivalent for boucle (qui en fait construit une liste), probablement parce qu'elle n'a pas de consulter la liste et sa append méthode à chaque itération. Cependant, une compréhension de liste ne fonctionne toujours un bytecode niveau de la boucle:

>>> dis.dis(<the code object for `[x for x in range(10)]`>)
 1           0 BUILD_LIST               0
             3 LOAD_FAST                0 (.0)
       >>    6 FOR_ITER                12 (to 21)
             9 STORE_FAST               1 (x)
            12 LOAD_FAST                1 (x)
            15 LIST_APPEND              2
            18 JUMP_ABSOLUTE            6
       >>   21 RETURN_VALUE

À l'aide d'une compréhension de liste à la place d'une boucle qui n'est pas construire une liste, inepte à accumuler une liste de sens des valeurs, puis de le jeter à la liste, est souvent plus lent en raison de la charge de la création et de l'extension de la liste. Interprétations de la liste ne sont pas de la magie qui est intrinsèquement plus rapide qu'un bon vieux boucle.

Comme pour la fonctionnelle de la liste de fonctions de traitement: Alors que ceux-ci sont écrits en C et probablement surpasser l'équivalent de fonctions écrites en Python, ils sont pas nécessairement l'option la plus rapide. La vitesse devrait si la fonction est écrite en C trop. Mais la plupart des cas à l'aide d'un lambda (ou autre fonction Python), les frais généraux, à plusieurs reprises, la configuration de Python pile de cadres etc. mange de toutes les économies. Simplement faire le même travail en ligne, sans appels de fonction (par exemple, une compréhension de liste au lieu de map ou filter) est souvent légèrement plus rapide.

Supposons que, dans un jeu que je suis en développement, j'ai besoin de tirer complexe et énorme de cartes à l'aide de boucles. Cette question serait certainement pertinent, car si une liste-de la compréhension, par exemple, est en effet plus rapide, ce serait une bien meilleure option pour éviter les lag (Malgré le visuel de la complexité du code).

Les Chances sont, si ce type de code n'est pas déjà assez rapide lorsqu'il est écrit en bon non"optimisé" de Python, aucun montant de Python niveau de la micro-optimisation va le faire assez rapidement et vous devriez commencer à penser à tomber à C. de vastes micro-optimisations peuvent souvent accélérer code Python considérablement, il est faible (en valeur absolue) de limiter à cela. Par ailleurs, même avant que vous frappez ce plafond, il devient tout simplement plus rentable (15% de l'accélération de vs 300% de la vitesse avec le même effort) mordre la balle et écrire quelques C.

Vous demandez spécifiquement sur la map(), filter() et reduce(), mais je suppose que vous voulez savoir sur la programmation fonctionnelle en général. Pour l'avoir testé moi-même sur le problème de calcul des distances entre tous les points à l'intérieur d'un ensemble de points, la programmation fonctionnelle (à l'aide de la starmap fonction de l'intégré dans le module itertools) s'est avéré pour être un peu plus lent que pour les boucles (prise de 1,25 fois plus long, en fait). Voici un exemple de code que j'ai utilisé:

import itertools, time, math, random

class Point:
    def __init__(self,x,y):
        self.x, self.y = x, y

point_set = (Point(0, 0), Point(0, 1), Point(0, 2), Point(0, 3))
n_points = 100
pick_val = lambda : 10 * random.random() - 5
large_set = [Point(pick_val(), pick_val()) for _ in range(n_points)]
    # the distance function
f_dist = lambda x0, x1, y0, y1: math.sqrt((x0 - x1) ** 2 + (y0 - y1) ** 2)
    # go through each point, get its distance from all remaining points 
f_pos = lambda p1, p2: (p1.x, p2.x, p1.y, p2.y)

extract_dists = lambda x: itertools.starmap(f_dist, 
                          itertools.starmap(f_pos, 
                          itertools.combinations(x, 2)))

print('Distances:', list(extract_dists(point_set)))

t0_f = time.time()
list(extract_dists(large_set))
dt_f = time.time() - t0_f

Est la version fonctionnelle plus rapide que la version procédurale?

def extract_dists_procedural(pts):
    n_pts = len(pts)
    l = []    
    for k_p1 in range(n_pts - 1):
        for k_p2 in range(k_p1, n_pts):
            l.append((pts[k_p1].x - pts[k_p2].x) ** 2 +
                     (pts[k_p1].y - pts[k_p2].y) ** 2)
    return l

t0_p = time.time()
list(extract_dists_procedural(large_set)) 
    # using list() on the assumption that
    # it eats up as much time as in the functional version

dt_p = time.time() - t0_p

f_vs_p = dt_p / dt_f
if f_vs_p >= 1.0:
    print('Time benefit of functional progamming:', f_vs_p, 
          'times as fast for', n_points, 'points')
else:
    print('Time penalty of functional programming:', 1 / f_vs_p, 
          'times as slow for', n_points, 'points')

Ajoutant une touche de Alphii répondre, en fait, la boucle serait le deuxième meilleur et environ 6 fois plus lent que map

from functools import reduce
import datetime


def time_it(func, numbers, *args):
    start_t = datetime.datetime.now()
    for i in range(numbers):
        func(args[0])
    print (datetime.datetime.now()-start_t)

def square_sum1(numbers):
    return reduce(lambda sum, next: sum+next**2, numbers, 0)


def square_sum2(numbers):
    a = 0
    for i in numbers:
        a += i**2
    return a

def square_sum3(numbers):
    a = 0
    map(lambda x: a+x**2, numbers)
    return a

def square_sum4(numbers):
    a = 0
    return [a+i**2 for i in numbers]

time_it(square_sum1, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum2, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum3, 100000, [1, 2, 5, 3, 1, 2, 5, 3])
time_it(square_sum4, 100000, [1, 2, 5, 3, 1, 2, 5, 3])

Principaux changements ont été d'éliminer les lentes sum appels, ainsi que le probablement inutile int() dans le dernier cas. Mettre la boucle for et la carte dans les mêmes termes, bien fait, en fait. Rappelez-vous que les lambdas sont les concepts de fonctions et, théoriquement, ne devrait pas avoir d'effets secondaires, mais, bon, ils peut avoir des effets secondaires comme l'ajout de a.
Les résultats dans ce cas avec Python 3.6.1, Ubuntu 14.04, Intel(R) Core(TM) i7-4770 CPU @ 3.40 GHz

0:00:00.257703
0:00:00.184898
0:00:00.031718
0:00:00.212699