Discussion :

[Sve@r]

Bonjour à tous

Je développe depuis un certain temps en Python et j'ai pris une certaine habitude. Et je viens ici afin d'avoir des conseils savoir si ce que je fais est bien ou pas.

Cela part au départ d'un objet style toto qui contient une méthode style start()

Code Python :

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

1
2
3
4
class toto:
    def start(self):
        ...
# class toto

Ensuite, il m'arrive d'avoir non pas une instance mais un tableau d'instances, style

Code Python :

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

tab=[toto(), toto(), toto(), toto(), toto()]

Et là où je veux en venir, c'est quand je veux appeler toutes les méthodes start. J'ai donc 2 façons de faire

La première, une boucle classique

Code Python :

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

1
2
for t in tab:
    t.start()

Et la seconde, passer par une list comprehension

Code Python :

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

[t.start() for t in tab]

Et moi, je prends de plus en plus l'habitude de passer par la seconde méthode car c'est plus pratique à écrire. Surtout si je dois en plus filtrer certains éléments

Code Python :

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

1
2
3
for t in tab:
    if t...:
        t.start()

Code Python :

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

[t.start() for t in tab if t...]

Mais ce qui me gène c'est que dans la seconde méthode je génère une liste pour rien puisque je ne la récupère pas.

Et donc je venais ici afin d'avoir vos avis sur les deux façons de faire et la meilleure à utiliser pour éviter de gaspiller des ressources.

Merci

[Zavonen]

Pour moi il ne sert à rien de construire des objets que l'on n'utilise pas.
La construction de ces objets peut être longue, la place qu'ils occupent en mémoire peut être importante.
Si on ne fait rien au niveau global des résultats du filtrage que l'appel d'une méthode pour les éléments filtrés il n'y a aucune raison d'utiliser une 'list comprehension'.
La boucle classique simple me parait plus adaptée.

[dividee]

Je suis d'accord avec Zavonen, mais plus pour des raisons stylistiques que pour des raisons de performances ou de gaspillage des ressources.
Maintenant, si la méthode start retourne quelque chose d'intéressant, et que tu fais quelque chose du résultat, ce serait une autre histoire...

On peut éviter la création d'une liste inutile et rendre ça un peu plus joli comme ceci:

Code :

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

1
2
3
4
def execute(it):
    for e in it: pass
 
execute(t.start() for t in tab if t ...)

* On utilise une generator expression au lieu d'une list comprehension
* Mais alors, on doit itérer dessus pour que les fonctions soient appelées
* On abstrait l'itération dans une fonction, et on en profite pour lui donner un nom qui insiste bien sur le fait qu'on l'appelle pour ses effets de bords (càd qu'on se fout de la valeur de retour).

[wiztricks]

Salut,

map(toto.start, tab), pour rappeler que les méthodes sont aussi des fonctions appliquées à une instance.
Sinon, en passant par les generators:
start = ( it.start() for it in tab if...)
On peut se contenter de: list(start) pour forcer la chose i.e. pourquoi passer par execute.
- W

[tyrtamos]

Bonjour,

En ce qui me concerne, je privilégie systématiquement la clarté du code, de sorte que dans 6 mois, je verrai du 1er coup d'œil ce que ça doit faire. Je préfère donc nettement la solution basique:

Code :

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

1
2
3
 
for t in tab:
    t.start()

Comme en plus cette solution 'basique' est très facilement adaptable (filtrage) et ne pose pas de pb de consommation de ressources inutiles, c'est encore mieux.

Tyrtamos

[dividee]

On peut se contenter de: list(start) pour forcer la chose i.e. pourquoi passer par execute.
- W

Oui, bah, c'était pour éviter l'allocation de mémoire de la liste, et insister sur le fait que le résultat (la liste de résultats) ne nous intéresse pas.

Mais bon, c'était surtout pour élaborer un peu sur la question. Concrètement, je ferais comme Zavonen et tyrtamos, une boucle "impérative".

[Sve@r]

Ouais, merci beaucoup pour tous ces avis éclairés.

J'avais bien l'intuition qu'une liste comprehension c'était pas optimum comme soluce.

En lisant la réponse de wiztricks, je me suis souvenu que cette façon de coder que je m'étais appropriée avait en fait été suggérée par je ne sais plus quel tuto/faq Python qui disait que les list comprehension étaient plus rapides que les map.

J'ai pas retrouvé le tuto/faq dans lequel j'ai lu ça mais j'en ai trouvé un autre qui dit sensiblement la même chose => http://www.biologeek.com/bonnes-prat...comprehensions Et cet autre aussi qui dit en plus que bientôt les map disparaitront => http://inaps.org/articles/developpem...liste-exemples

[PauseKawa]

Bonsoir,

Désolé pour l'incursion dans le sujet mais:

c'était pour éviter l'allocation de mémoire de la liste, et insister sur le fait que le résultat (la liste de résultats) ne nous intéresse pas.

Code :

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

1
2
3
4
def execute(it):
    for e in it: pass
 
execute(t.start() for t in tab if t ...)

Ou est l'occupation mémoire par rapport à un:

Code :

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

1
2
3
4
5
6
7
8
class toto:
    def start(self):
        print ('pass')
 
tab=[toto(), toto(), toto()]
 
for it in (items for items in tab if items.start):
    it.start()

?

Merci

[dividee]

@Sve@r:
map, filter & co ne disparaîtront certainement jamais. Au pire, ils ne seront plus des builtins mais dans un module de la librairie standard. Et si ça arrive, ça m'étonnerais que ce soit de si tôt.

Si tu lis jusqu'au bout le premier lien que tu as posté, tu verras que ce n'est pas aussi simple que ça, niveau performance. Les lists comprehensions sont plus rapides sur de petites quantités de données, car l'overhead des appels de fonctions (à map ou filter) est relativement élevé. Mais sur des listes plus grandes, map et filter sont en fait plus rapides. J'ai pu le vérifier en Python 2.7

@PauseKawa: ton code évite aussi l'allocation de mémoire, c'était par rapport à une list comprehension ou un map

[PauseKawa]

Si tu lis jusqu'au bout le premier lien que tu as posté, tu verras que ce n'est pas aussi simple que ça, niveau performance. Les lists comprehensions sont plus rapides sur de petites quantités de données, car l'overhead des appels de fonctions (à map ou filter) est relativement élevé. Mais sur des listes plus grandes, map et filter sont en fait plus rapides. J'ai pu le vérifier en Python 2.7

Étonnant. Il me semblais que l'utilisation directe de built in (ainsi que de locales) était toujours plus rapide du fait du code. Un exemple ?

[dividee]

Étonnant. Il me semblais que l'utilisation directe de built in (ainsi que de locales) était toujours plus rapide du fait du code. Un exemple ?

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
29
30
31
32
33
from time import clock
 
def t(f,*args):
    t0 = clock()
    f(*args)
    return clock() - t0
 
from random import randint
l = [randint(-100,100) for _ in xrange(1000000)]
 
def map1():
    map(abs,l)
 
def map2():
    [abs(i) for i in l]
 
def odd(n):
    return n & 1
 
def map_filter1():
    map(abs, filter(odd, l))
 
def map_filter2():
    [abs(i) for i in l if odd(i)]
 
def map_filter3():
    [abs(i) for i in l if i & 1]
 
print 'map1:', t(map1), 's'
print 'map2:', t(map2), 's'
print 'map_filter1:', t(map_filter1), 's'
print 'map_filter2:', t(map_filter2), 's'
print 'map_filter3:', t(map_filter3), 's'

Résultat:

Code :

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

1
2
3
4
5
map1: 0.089907232765 s
map2: 0.149724136161 s
map_filter1: 0.225532160591 s
map_filter2: 0.280151276031 s
map_filter3: 0.146270705827 s

Ce qui est réellement coûteux, ce sont les appels de fonctions. map_filter3 a l'avantage quand on 'inline' la fonction, ce qui n'est pas possible avec map & filter sans passer par une lambda, qui n'offre aucun gain de temps par rapport à un appel de fonction.

Conclusion: un "simple" map est plus rapide qu'une list comprehension (pour peu qu'il y ait plus d'une poignée d'éléments), mais s'il faut également faire du filtrage, la list compr. sera normalement plus efficace si elle permet d'éviter des appels de fonctions.

[Sve@r]

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
29
30
31
32
33
from time import clock
 
def t(f,*args):
    t0 = clock()
    f(*args)
    return clock() - t0
 
from random import randint
l = [randint(-100,100) for _ in xrange(1000000)]
 
def map1():
    map(abs,l)
 
def map2():
    [abs(i) for i in l]
 
def odd(n):
    return n & 1
 
def map_filter1():
    map(abs, filter(odd, l))
 
def map_filter2():
    [abs(i) for i in l if odd(i)]
 
def map_filter3():
    [abs(i) for i in l if i & 1]
 
print 'map1:', t(map1), 's'
print 'map2:', t(map2), 's'
print 'map_filter1:', t(map_filter1), 's'
print 'map_filter2:', t(map_filter2), 's'
print 'map_filter3:', t(map_filter3), 's'

Résultat:

Code :

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

1
2
3
4
5
map1: 0.089907232765 s
map2: 0.149724136161 s
map_filter1: 0.225532160591 s
map_filter2: 0.280151276031 s
map_filter3: 0.146270705827 s

Ce qui est réellement coûteux, ce sont les appels de fonctions. map_filter3 a l'avantage quand on 'inline' la fonction, ce qui n'est pas possible avec map & filter sans passer par une lambda, qui n'offre aucun gain de temps par rapport à un appel de fonction.

Conclusion: un "simple" map est plus rapide qu'une list comprehension (pour peu qu'il y ait plus d'une poignée d'éléments), mais s'il faut également faire du filtrage, la list compr. sera normalement plus efficace si elle permet d'éviter des appels de fonctions.

Joli exemple de Benchmarck. Maîtrise du Python à un niveau qui me fait envie. Mais *arg n'est pas utile n'est-ce pas ???

Sinon de mon coté aujourd'hui j'ai repris tous mes codes et remplacé chaque list comprehension inutiles par une classique boucle for. Heureusement j'avais la commande magique pour trouver les sources concernés => grep -l " [" $(find . -name "*.py" -print)

[dividee]

Joli exemple de Benchmarck. Maîtrise du Python à un niveau qui me fait envie. Mais *arg n'est pas utile n'est-ce pas ???

Merci pour le compliment. Effectivement, *args n'est pas utile, mais j'ai écris la fonction [i]t[/t] en premier et je ne savais pas encore exactement comment j'allais l'utiliser...

[PauseKawa]

Bonsoir,

Ce qui est réellement coûteux, ce sont les appels de fonctions. map_filter3 a l'avantage quand on 'inline' la fonction, ce qui n'est pas possible avec map & filter sans passer par une lambda, qui n'offre aucun gain de temps par rapport à un appel de fonction.

Conclusion: un "simple" map est plus rapide qu'une list comprehension (pour peu qu'il y ait plus d'une poignée d'éléments), mais s'il faut également faire du filtrage, la list compr. sera normalement plus efficace si elle permet d'éviter des appels de fonctions.

J'avais bien compris dividee.

Étonnant. Il me semblais que l'utilisation directe de built in (ainsi que de locales) était toujours plus rapide du fait du code. Un exemple ?

Merci pour l'exemple

Bon code