Discussion :

[Gui13]

Bonjour à tous,

Je suis entrain d'écrire un programme en python pour générer des graphiques de mes données GPS.

Je me demandais quel serait le code le plus rapide:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
gpsData = csv.reader(open('E:\gps.csv'))
 
 
# format: type,time,latitude,longitude,altitude (m),speed (km/h)
 
# celui-là?
lat = [row[2] for row in gpsData]
speeds= [row[4] for row in gpsData]
 
# ou celui-là?
for row in gpsData:
    lat.append(row[2])
    speeds.append(row[4])

J'ai cru lire pas mal de fois que les "list-comprehension" sont plus rapide, mais ce que je comprends dans le code ci dessus, c'est que je vais parcourir la liste 2 fois, alors qu'avec ma boucle for je ne la parcours qu'une seule fois.

Un avis? Des conseils pour rendre le code "plus propre"?

[PauseKawa]

Bonjour,

Perso je pense que le for est plus rapide mais pourquoi ne pas tester toi même avec un time ?

@+

[Antoine_935]

Il y a pour l'instant une recrudescence de « plus vite » sur ce forum. Et, à chaque fois, on n'est pas à 2ms près.

Alors je crois qu'il est temps d'arrêter de penser « plus vite » et de commencer à penser « plus solide ». C'est d'ailleurs à ça que servent les langages de haut niveau comme le Python.

Mais si vous tenez à gagner ces quelque précieuses (?) milisecondes, pensez à coder en C. Mais alors faites tout en C, parce que pour ce que vous allez gagner si vous faites seulement ça, le jeu n'en vaut pas la chandèle.

En plus, ce qui va vous ralentir ici, ce sera la lecture du fichier. Pour vraiment y aller à fond, faudra lancer les lectures en asynchrone, et traiter les données déjà obtenues pdt que le disque va gentiment chercher les données de son côté.

Alors si vous voulez gagner du temps à l'exécution, ne soyez pas si petit joueur. Faites vous vraiment plaisir, pas à moitié en discutaillant de détails tels que ceux-ci.


Et quand je parle de plus solide, c'est pas pour dire des idioties. En voulant utiliser des list comprehension pour « améliorer les performances », vous vous retrouvez avec un bug.

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
>>> import csv
>>> with open("dat.csv") as f:
...     reader = csv.reader(f)
...     
...     for l in reader:
...         print l
...     
...     print "again ?"
...     
...     for l in reader:
...         print l
... 
['un', 'deux', 'trois']
['un', 'deux', 'trois', 'quatre']
again ?

[Zavonen]

Mais si vous tenez à gagner ces quelque précieuses (?) milisecondes, pensez à coder en C. Mais alors faites tout en C, parce que pour ce que vous allez gagner si vous faites seulement ça, le jeu n'en vaut pas la chandèle.

Presque entièrement d'accord avec toi Antoine!
Mais il arrive qu'un programme rame parce qu'il est mal conçu (boucles imbriquées sans tests de sortie, etc...). Il peut être bon, avant de coder en C (étape finale) de comparer les perfs des algos dans un langage de haut niveau. Mais pour les opérations d'E/S il y a trop d'aléatoire (système d'exploitation, qualité des périphériques, etc...)
Pour mesurer l'efficacité d'une fonction sous python le mieux est de la 'décorer':

Code python :

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
 
import math
import time
 
def time_this(func):
    """Le décorateur qui mesure le temps mis"""
    def decorated(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        print "Exécuté en", time.time() - start, "secondes"
        return result
    return decorated
 
X=math.pi
 
@time_this
def loop1():
    for i in xrange(0,100000):
        Y=math.pow(X,2.0)
@time_this
def loop2():
    for i in xrange(0,100000):
        Y=X*X
 
if __name__ == "__main__":
    loop1()
    loop2()

Pour le bug par contre je ne comprends pas:
Il n'y a pas de 'comprehension list' dans le bout de code
Que contient le fichier ?
Où est le bug et pourquoi.
Si tu as le temps explique un peu.

[Antoine_935]

Où est le bug et pourquoi.

cvs.reader lit et parse le fichier ligne par ligne. Comme il lit les lignes du fichier, le curseur de ce dernier avance. À la fin de la boucle, on est arrivé à la fin du fichier. À moins de repositionner le curseur en début de fichier, la deuxième boucle ne fera même pas une itération.

Or, une list comprehension n'est rien d'autre qu'une boucle élégamment écrite. On aura donc le même bug.

Le fichier, c'est juste ça :

Code :

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

1
2
un,deux,trois
un,deux,trois,quatre

[dividee]

Il y a pour l'instant une recrudescence de « plus vite » sur ce forum. Et, à chaque fois, on n'est pas à 2ms près.

Alors je crois qu'il est temps d'arrêter de penser « plus vite » et de commencer à penser « plus solide ». C'est d'ailleurs à ça que servent les langages de haut niveau comme le Python.

On cite souvent Knuth dans ce cas (Premature optimizations is the root of all evil), mais je viens de trouver un autre citation sympathique:

The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet. (Michael A. Jackson)

[dividee]

Je m'écarte un peu de la question initiale, mais j'aimerais examiner une autre possibilité:

Code :

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

samples = [(row[2],row(4)) for row in gpsData]

C'est à dire utiliser un tableau de tuples au lieu de deux tableaux. On ne parcourt qu'une seule fois gpsData donc il n'y a pas le problème mentionné par Antoine. L'intérêt va dépendre des traitements appliqués. Si les deux tableaux doivent généralement être parcourus parallèlement, on est obligé de passer par des indices ou zip:

Code :

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

1
2
for i in range(len(lat)):
    ... lat[i] ... speeds[i]

Code :

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

1
2
for l,s in zip(lat, speeds):
    ... l ... s

Avec le tableau de tuple, c'est plus simple et il n'y a pas le coût de zip:

Code :

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

1
2
 for l,s in samples:
    ... l ... s

[eyquem]

Je suis d’accord avec Antoine_935 et aussi avec Zavonen.


Sauf que je ne vois pas quels sont les files concernées par ta critique anti-speedite , Antoine.

Je ne vois que la file “Optimisation des boucles for “ de Kikouyou1080 dans la première page du forum qui se préoccupe d’accélération d’un programme, mais celui ci est un traitement d’image donc on comprend que cela soit important.





Je suis très d’accord avec toi: l’essentiel de l’intérêt de Python: est d’être un langage de haut niveau d’abstraction.

Et si on reste obnubilé par la vitesse, cela peut freiner l’apprentissage de ses riches possibilités. Ce fut mon cas pendant un certain temps, avant que je comprenne combien il était vain d’utiliser Python avec des préoccupations qu’on a en langage C.




Cependant, il ne faut pas trop tirer à boulet rouge sur cette tendance:

- on ne peut pas comprendre ça du jour au lendamain, il faut bien laisser le temps calmer de lui-même les speedites.

- quand on lit de la part de pratiquants d’autres langages que Python ne vaut rien parce qu’il est lent, ça file un peu des complexes au début. Ça peut créer le désir de remontrer de quoi est capable Python

- Si tu tapes ainsi sur une fort innocente question d’un pratiquant de Python, j’aimerais lire les flêches que tu pourrais décocher contre les pratiquants de C++ qui s’enferment dans l’ascétique choix d’utliser C++ au prétexte qu’il est très rapide, même si le gain de vitesse qu’ils en retirent ne doit pas avoir une réelle importance dans plus de 50% des cas et ne justifie à mon avis pas toutes leurs souffrances

- il ne faut pas négliger que la recherche de vitesse est aussi un bon stimulant pour se triturer les méninges et décortiquer les processus de Python pour comprendre ce qui détermine une lenteur ici ou là, et c’est très formateur aussi.

- se préoccuper de vitesse peut conduire à chambouler son algorithme, car d’expérience j’ai constaté que c’est la qualité de l’algo qui fait la rapidité, et pas tellement telle ou telle astuce. Une lenteur d’exécution peut donc être signe de mauvais algorithme.






Concernant ta remarque sur le bug , je ne trouve pas que ce soit un très bon argument contre la recherche de vitesse. Parce que même sans csv.reader, et sans list comprehension, on peut se retrouver avec ce bug en faisant simplement:

for ligne in f:
instructions
for ligne in f:
instructions

si on ne pense pas à mettre f.seek(0) entre les deux boucles.

Je pense que tu as voulu dire que se polariser sur la vitesse peut faire oublier les choses importantes.
Mais quelqu’un d’expérimenté pourra faire les deux.







Bon, j’ai cédé à mon gôut des comparatifs.

J’ai créé un fichier grossier avec

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
import csv
 
# format: type,time,latitude,longitude,altitude (m),speed (km/h)
 
 
type = ('gloubi','glouba','athos','aramis','porthos')
time = ('23h45','23h12','02h45','09h47','17h22','07h00','05h11')
latitude = ('12deg13\'','45deg23\'','78deg33\'','67deg59\'','02deg04\'')
longitude = ('-150deg45\'','+65deg29\'','123deg25\'','12deg52\'','9deg27\'','56deg13\'')
altitude = ('1234','345','23','-4','78','437','389','233','19')
 
f = open('gps.csv','w')
 
import random
 
for i in range(500):
 
    ty = random.choice(type)
    ti = random.choice(time)
    la = random.choice(latitude)
    lo = random.choice(longitude)
    al = random.choice(altitude)
    sp = str(random.randrange(0,370))
 
    f.write(ty+','+ti+','+la+','+lo+','+al+','+sp+'\n')
 
f.close()

Et j’ai fait tourner

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
import csv,re
from time import clock
 
 
# format: type,time,latitude,longitude,altitude (m),speed (km/h)
 
# celui-là?   ##1
 
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
lat1 = [row[2] for row in gpsData]
f.seek(0)
speeds1= [row[4] for row in gpsData]
dt = clock()-te
f.close()
print('lat1 = [row[2] for row in gpsData]   speeds1= [row[4] for row in gpsData]')
print(dt)
print()
 
 
# ou celui-là?  ##2
 
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
lat2 = []
speeds2 = []
for row in gpsData:
    lat2.append(row[2])
    speeds2.append(row[4])
dt = clock()-te
f.close()
print('for row in gpsData:   lat2.append(row[2])    speeds2.append(row[4])')
print(dt)
print()
 
 
##3
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
w =  [(row[2],row[4]) for row in gpsData]
lat3= [ u for (u,v) in w]
speeds3= [ v for (u,v) in w]
dt = clock()-te
f.close()
print('w =  [(row[2],row[4]) for row in gpsData] ]')
print(dt)
print()
 
 
##4
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
lat4 = []
speeds4 =[]
[(lat4.append(row[2]),speeds4.append(row[4])) for row in gpsData]
dt = clock()-te
f.close()
print('[(lat4.append(row[2]),speeds4.append(row[4])) for row in gpsData]')
print(dt)
print()
 
 
##5
f = open('gps.csv')
RE = '[^,]+,[^,]+,([^,]+),[^,]+,([^,]+),.+'
 
te = clock()
uh = f.read()
lat5 = []
speeds5 = []
[(lat5.append(match.group(1)),speeds5.append(match.group(2))) for match in re.finditer(RE,uh) ]
dt = clock()-te
f.close()
print('[(lat5.append(match.group(1)),speeds5.append(match.group(2))) for match in re.finditer(RE,uh) ]')
print(dt)
print()
 
 
print('lat1==lat2==lat3==lat4==lat5  est ',lat1==lat2==lat3==lat4==lat5)
print('speeds1==speeds2==speeds3==speeds4==speeds5  est',speeds1==speeds2==speeds3==speeds4==speeds5)
print()
#print(lat1)
print()
#print(speeds1)

Un résultat typique:

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
lat1 = [row[2] for row in gpsData]   speeds1= [row[4] for row in gpsData]
0.0391158652846
 
for row in gpsData:   lat2.append(row[2])    speeds2.append(row[4])
0.0115296776546
 
w =  [(row[2],row[4]) for row in gpsData] ]
0.0113310490579
 
[(lat4.append(row[2]),speeds4.append(row[4])) for row in gpsData]
0.011168179196
 
[(lat5.append(match.group(1)),speeds5.append(match.group(2))) for match in re.finditer(RE,uh) ]
0.0142490176824
 
lat1==lat2==lat3==lat4==lat5  est  True
speeds1==speeds2==speeds3==speeds4==speeds5  est True

Sans surprise. deux itérations dans un fichier , même avec list comprehension, prennent plus de temps qu’une seule (1)


Une seule itération avec deux append est plus rapide (2)


De façon surprenante, une seule itération, construction d’une liste de doublets et extraction de lat et speed à partir de cette liste n’est pas plus lent. (3)


Une écriture que j’ai trouvée en cherchant des astuces alors que j’étais atteint d’une autre maladie, la concisionnite:
mettre deux instructions dans un tuple “exécuté“ dans une liste comprehension.
Et ça marche ! Sur plusieurs essais, ça me donne l’impression d’être même le plus souvent très légèrement en dessous du temps de la méthode 2. Mais de très trés peu. Cependant ça conjugue vitesse et concision (4)


L’utilisation d’une regex: c’est 20 % de temps au dessus des solutions 2-3-4.




Que conclure ?

[Antoine_935]

Sauf que je ne vois pas quels sont les files concernées par ta critique anti-speedite , Antoine.

Vitesse d'exploitation d'une variable :
http://www.developpez.net/forums/d93...tion-variable/

Optimisation de boucle for (quoique celui-ci me parait plus justifié):
http://www.developpez.net/forums/d93...n-boucles-for/

Rapidité de traitement :
http://www.developpez.net/forums/d93...te-traitement/

- Si tu tapes ainsi sur une fort innocente question d’un pratiquant de Python, j’aimerais lire les flêches que tu pourrais décocher contre les pratiquants de C++ qui s’enferment dans l’ascétique choix d’utliser C++ au prétexte qu’il est très rapide, même si le gain de vitesse qu’ils en retirent ne doit pas avoir une réelle importance dans plus de 50% des cas et ne justifie à mon avis pas toutes leurs souffrances

C'est vrai, je n'aime pas le C++. Je suis par contre un grand adorateur du C. Le C++, à mon sens, est un langage rafistolé. Qui rafistole je ne sais quoi d'ailleurs, puisque tout ce qu'on fait en C++, on peut le faire en C.

Alan Kay, un des pionniers de l'orienté objet, a déclaré :

Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.

En fait j'ai inventé le terme d'«orienté objet», et je peux vous dire que je n'avais pas le C++ en tête.

Eh oui, le C++ n'est visiblement pas une merveille aux yeux de tous.

- il ne faut pas négliger que la recherche de vitesse est aussi un bon stimulant pour se triturer les méninges et décortiquer les processus de Python pour comprendre ce qui détermine une lenteur ici ou là, et c’est très formateur aussi.

- se préoccuper de vitesse peut conduire à chambouler son algorithme, car d’expérience j’ai constaté que c’est la qualité de l’algo qui fait la rapidité, et pas tellement telle ou telle astuce. Une lenteur d’exécution peut donc être signe de mauvais algorithme.

C'est vrai.

Je pense que tu as voulu dire que se polariser sur la vitesse peut faire oublier les choses importantes.

C'était bien le message, aussi mal formulé soit-il


J'ai un peu profité de ton code pour jouer aussi, et voici les résultats que j'ai obtenu. Ma clock semble bien moins précise... j'ai du monter le nombre de lignes à... 200000 (deux cent milles). Ca montre encore une fois que la différence de vitesse est négligeable.

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
import csv,re
from time import clock
 
 
# format: type,time,latitude,longitude,altitude (m),speed (km/h)
 
# celui-la ?   ##1
 
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
lat1 = []
speeds1 = []
appendLat = lat1.append
appendSpeed = speeds1.append
for row in gpsData:
    appendLat(row[2])
    appendSpeed(row[4])
dt = clock()-te
f.close()
print('for row in gpsData:   appendLat(row[2])    appendSpeed(row[4])')
print(dt)
print()
 
# ou celui-la ?  ##2
 
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
lat2 = []
speeds2 = []
for row in gpsData:
    lat2.append(row[2])
    speeds2.append(row[4])
dt = clock()-te
f.close()
print('for row in gpsData:   lat2.append(row[2])    speeds2.append(row[4])')
print(dt)
print()
 
# Ou encore
 
f = open('gps.csv')
te = clock()
gpsData = csv.reader(f)
lat2 = []
speeds2 = []
 
appendLat = lat1.append
appendSpeed = speeds1.append
 
mapper = lambda x: appendLat(row[2]); appendSpeed(row[4])
filter(mapper, gpsData)
dt = clock()-te
f.close()
print('mapper = lambda x: appendLat(row[2]); appendSpeed(row[4])')
print(dt)
print()

Et les résultats :

Code :

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

1
2
3
4
5
6
7
8
for row in gpsData:   appendLat(row[2])    appendSpeed(row[4])
0.2
 
for row in gpsData:   lat2.append(row[2])    speeds2.append(row[4])
0.22
 
mapper = lambda x: appendLat(row[2]); appendSpeed(row[4])
0.18

[Zavonen]

cvs.reader lit et parse le fichier ligne par ligne. Comme il lit les lignes du fichier, le curseur de ce dernier avance. À la fin de la boucle, on est arrivé à la fin du fichier. À moins de repositionner le curseur en début de fichier, la deuxième boucle ne fera même pas une itération.

Oui, ça c'est clair, mais je ne vois toujours pas le rapport avec les 'comprehension lists'
Cela n'a rien à voir.

[Gui13]

Wow, je ne m'attendais pas à autant de réponses!

Voici ce que j'ai fait:
je suis très rapidement tombé sur le bug qu'Antoine a donné (cvs.reader qui arrive en fin de fichier), ce qui signifie tout simplement que les "list comprehensions" ne sont pas adaptées dans ce cas là (ou alors il faut un moyen de "rembobiner" le cvs.reader, je n'ai pas regardé).
Du coup j'ai codé ça avec une boucle simple.


Dans tous les cas, la remarque de dividee est très intéressante.

Le but final de mon code est de pouvoir tracer des courbes extraites des données GPS. J'ai terminé l'extraction des données hier soir, mais je me cogne à la fonction plot() de pylab/matlibplot


Voici mon code, pour information:

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
34
35
36
37
38
39
40
41
42
43
# -*- coding: cp1252 -*-
import csv
import matplotlib
import time as t
 
matplotlib.use('Qt4Agg')
 
import matplotlib.pyplot as plt
 
# récupere les données du CSV
gpsData = csv.reader(open('E:\gps.csv'))
# dataDict = csv.DictReader(open('E:\gps.csv')) # todo?
 
# format: type,time,latitude,longitude,altitude (m),speed (km/h)
 
speeds = []
lat = []
lon = []
elevations = []
time = []
 
# data = {"vitesse":speeds, "latitude":lat, "Longitude":lon, "Elevation":elevations, "Date":time} # todo ?
 
u=0
for row in gpsData:
    # append real data in the lists
    try:
        time.append(t.mktime(t.strptime(row[1], "%d/%m/%y %H:%M")))
    except ValueError:
        time.append(0)
    lat.append(row[2])
    lon.append(row[3])
    elevations.append(row[4])
    speeds.append(row[5])
    u +=1
#	if u%100 == 0:
#        print "Processing row ",u,":", row
 
for key,value in data.iteritems():
    print "Length of ", key, " : ", len(value)
 
a = plt.plot(speeds[1:], time[1:]) # le premier élément est le titre
b = plt.show() # plante ...