Benchmark conversion list-->numpy.array

Bonjour à tous

Je cherche différent moyen de caster une liste (ou une portion de liste) en un numpy array. J'aurais besoin de plusieurs méthodes différentes selon les besoins/la situation alors je me disais pourquoi pas faire une classe qui dériverait de list et qui ajouterais à ce type les différentes méthodes de cast vers un array que je souhaites proposer.

Code:

---

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

import numpy as np from time import time   datasize=10000   rd = np.random.RandomState(seed=0) data = list( rd.rand(datasize) )     #### Option 1 : Une fonction exterieur def to_nparray(datalist): return np.array(datalist)   #### Option 2 : On creer une classe qui derive de list class MyList(list): def to_nparray(self): return np.array(self)   data2 = MyList(data)   Niter4access = int(1e7) Niter4nparr_cast= int(1e4)   t0 = time() for i in range(Niter4access) : b=data[i%datasize] t1 = time() for i in range(Niter4access) : b=data2[i%datasize] t2 = time() for i in range(Niter4nparr_cast) : b=to_nparray(data) t3 = time() for i in range(Niter4nparr_cast) : b=data2.to_nparray() t4 = time()   print("======== Exec time ========") print("-- Particular acces (%s iter) ---"%Niter4access) print("External fct: %s"%(t1-t0)) print("Class method: %s"%(t2-t1)) print("-- np.array cast (%s iter) ---"%Niter4nparr_cast) print("External fct: %s"%(t3-t2)) print("Class method: %s"%(t4-t3))

---

A ma grande stupeur faire une nouvelle classe est donc bien plus couteux !

Code:

---

1 2 3 4 5 6 7

======== Exec time ======== -- Particular acces (10000000 iter) --- External fct: 1.5281527042388916 Class method: 2.4622461795806885 -- np.array cast (10000 iter) --- External fct: 5.599560022354126 Class method: 6.787678480148315

---

Quelqu'un peut-il tester chez lui et me dire s'il a les mêmes différences entre les 2 cas ? Qqn a-t-il une explication de pourquoi y a t il autant de différence sur le temps d'éxécution (+60% en coût sur l'accès particulaire tout de même ce n'est pas rien, et +27% sur la conversion ). Je sais qu'on rajoute une classe, donc c'est plus lourd. Mais à ce point ...

Bonjour,

Au début, je pensais que tu étais sur un cas trompeur, car les temps que tu montres pourraient laisser penser que c'est juste l'initialisation de l'objet qui est un temps incompressible, j'ai donc refait ton test mais en multipliant par 10 les ranges, et là, on voit bien une différence qui n'est pas lié uniquement à l'initialisation de l'objet:

Code:

---

1 2 3 4 5 6 7

======== Exec time ======== -- Particular acces (100000000 iter) --- External fct: 16.96150016784668 Class method: 27.86549997329712 -- np.array cast (100000 iter) --- External fct: 60.59150004386902 Class method: 74.43249988555908

---

Bon après, je n'ai pas l'explication mais je trouve ça moche...

La création des arrays est faite avant que je ne déclenche les chrono via time, donc ce temps là n'est pas compté dedans. Et on s'attends en effet à ce qu'à la création il y est un surcoût, mais celui là je suis prêt à le payer. Celui sur l'extraction où l'appel à la méthode, moins ....

Le fait que tu l'ait lancé (merci d'ailleurs pour ce temps que tu as pris) m'indique déjà que c'est à priori "normal" et pas lié à mon installation (tu as aussi un bon 60% d'augmentation du cout sur l'accès particulaire).

Si qqn a une explication je la veux bien.

Du coup, je vais opté pour un ensemble de fonctions externes plutôt qu'une nouvelle classe. Ca sera un peu plus crade car moins sémantique, mais là le prix est trop exhorbitant sur le nombre de fois où j'aurais à le faire. Si qqn a une solution intermédiaire, je suis preneur également.

Non, rien j'ai dit une connerie...

Bon, a priori, c'est une raison de recherche dans divers dictionnaire liée aux classe qui ferait ça...

Une petite explication (en anglais) : https://stackoverflow.com/questions/...s-twice-as-slo

Salut,

Même résultat et pas d'explications.

Citation:

---

Envoyé par disedorgue

Bon, a priori, c'est une raison de recherche dans divers dictionnaire liée aux classe qui ferait ça...

---

C'est une hypothèse qui se teste facilement en mettant la méthode appelée dans une variable (çà évite la recherche).
J'ai testé, il y a un petit mieux mais trop "petit" pour être l'explication.
Un autre test est d'appeler la fonction en lui passant l'instance en paramètre: même punition.

- W

Ok, tant pis, au moins ça élimine déjà une piste...

Il n'existe pas un outil qui permet de voir la pile d'exécution du moteur python pour voir la balade qu'il fait quand il s'agit d'une classe par exemple ?

Citation:

---

Envoyé par disedorgue

Il n'existe pas un outil qui permet de voir la pile d'exécution du moteur python pour voir la balade qu'il fait quand il s'agit d'une classe par exemple ?

---

Je ne sais pas.

Si on remplace l'appel à np.array par un truc qui balaie la liste, on trouve des résultats semblables (pourvu qu'on mette la méthode dans une variable histoire de bypasser la résolution de noms).

Si on évite l'héritage via:

Code:

---

1 2 3 4 5

class MyList: def __init__(self, alist): self._list = alist def to_nparray(self): return np.array(self._list)

---

J'obtiens aussi des résultats semblables.

Donc np.array semble bosser plus lorsqu'il ne récupère pas un type "natif", c'est par là qu'est l'indirection.
En tout cas, pour le problème de "base" çà donne un semblant de solution.

- W

Par contre, ça ne résout pas le 1er cas, l'accès particulaire, ou alors j'ai pas trouvé l'évidence:

J'ai du rajouter pour la class une method:

Code:

---

1 2	def __getitem__(self, i): return self._list[i]

---

Pour que le code de départ fonctionne.

Citation:

---

Envoyé par disedorgue

Par contre, ça ne résout pas le 1er cas, l'accès particulaire, ou alors j'ai pas trouvé l'évidence:

---

Ah ouais, je l'ai zappé celui là car on sait pourquoi (trouver la fonction à appeler dans le tas de __dict__).
C'est sûr que la forme littérale (liste[i]) est difficile à contourner... Et ajouter des indirections/appels de fonctions n'arrangera pas les choses. Si on zappe l'héritage, le plus simple sera de rendre l'attribut public et d'y accéder directement. Il y a peut être d'autres Pythonneries qui pourrait rendre les choses plus élégantes, mais là, je ne vois pas.

- W

Alors, sur ma petite machine perso (vieux dual core 32 bits) :

Pour la classe d'origine:

Code:

---

1 2 3

class MyList(list): def to_nparray(self): return np.array(self)

---

Les temps suivants:

Code:

---

1 2 3 4 5 6 7

======== Exec time ======== -- Particular acces (10000000 iter) --- External fct: 6.557446479797363 Class method: 9.392954111099243 -- np.array cast (10000 iter) --- External fct: 24.018495321273804 Class method: 29.008670568466187

---

Avec la classe suivante:

Code:

---

1 2 3 4 5 6 7 8 9

class MyList(list): def __init__(self, alist): self._list = alist   def __getitem__(self,i): return self._list[i]   def to_nparray(self): return np.array(self._list)

---

Les temps suivants:

Code:

---

1 2 3 4 5 6 7

======== Exec time ======== -- Particular acces (10000000 iter) --- External fct: 6.6995978355407715 Class method: 12.80150294303894 -- np.array cast (10000 iter) --- External fct: 24.882997512817383 Class method: 24.995436906814575

---

Et pour la classe suivante (qui semble être le meilleur compromis) :

Code:

---

1 2 3 4 5 6 7

class MyList(list): def __init__(self, alist): self._list = alist super().__init__(self._list)   def to_nparray(self): return np.array(self._list)

---

Les temps suivants:

Code:

---

1 2 3 4 5 6 7

======== Exec time ======== -- Particular acces (10000000 iter) --- External fct: 6.758497476577759 Class method: 9.66832685470581 -- np.array cast (10000 iter) --- External fct: 24.691341638565063 Class method: 24.85800290107727

---

Citation:

---

Envoyé par wiztricks

Si on évite l'héritage via:

Code:

---

1 2 3 4 5

class MyList: def __init__(self, alist): self._list = alist def to_nparray(self): return np.array(self._list)

---

J'obtiens aussi des résultats semblables.

Donc np.array semble bosser plus lorsqu'il ne récupère pas un type "natif", c'est par là qu'est l'indirection.
En tout cas, pour le problème de "base" çà donne un semblant de solution.

- W

---

La faute à numpy ? Bonne idée mais je viens de faire un test qui écarte cette hypothèse. Si dans mes classes je rajoutes des méthodes

Code:

---

1 2 3

class MyList(list): def to_tuple(self): return tuple(self)

---

On obtient aussi des écarts de temps considérables !

L'idée de disedorgue qui dérive la classe, mais qui aussi en plus garde une référence vers l'instance de la classe parent (comme l'avait proposé wiztricks, merci pour cette idée) permet d'avoir en effet un temps d'éxécution comparable sur les méthodes to_nparray (et to_tuple aussi au passage). Pour l'accès particulaire par contre, ca reste un mystère !

Ma classe n'étant là à la base que pour regrouper un ensemble de fonction de cast plus ou moins complexe, l'idée de laisser l'attribut publique perd un peu de son intérêt, puisque dès qu'on utilise une méthode autre qu'un cast on va devoir passer par cet attribut. Pour cette raison je vais adopté la 1ere solution (des méthodes externes), mais ceci dit, pour d'autres la solution suivante serait très nettement acceptable :

Code:

---

1 2 3 4 5 6 7

class MyList(list): def __init__(self, alist): self._list = alist super().__init__(self._list)   def to_nparray(self): return np.array(self._list)

---

fournit un temps comparable pour le cast, et seulement un poil plus pour l'accès particulaire sous réserve de l'écrire ainsi :

Code:

---

data._list[i]

---

plutot que

Code:

---

data[i]

---

L'accès particulaire perd un peu en performance du à l'indirection ( comme mentionné par un internaute dans le lien stackoverflow donné plus haut :

Citation:

---

An official Python performance guide reccomends to avoid dots in performance critical parts of the code: https://wiki.python.org/moin/PythonS...erformanceTips

---

) qui reste tout de même petit bien que non négligeable (exectime +18%) à côté des écarts monstrueux que je pouvais constater au départ (exectime +60%).

Je poste l'ensemble du code si jamais qqn en a besoin, ou souhaite à nouveau commenter/apporter sa contribution.

Code:

---

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 89 90 91

import numpy as np from time import time   #### Sujet developpez.net relie à ce code : ### https://www.developpez.net/forums/d1861888/autres-langages/python-zope/calcul-scientifique/benchmark-conversion-list-numpy-array/   datasize=10000   rd = np.random.RandomState(seed=0) data = list( rd.rand(datasize) )     #### Option 1 : Une fonction exterieur def to_nparray(datalist): return np.array(datalist)   def to_tuple(datalist): return tuple(datalist)   #### Option 2 : On creer une classe qui derive de list class MyList(list): def to_nparray(self): return np.array(self)   def to_tuple(self): return tuple(self)   #### Option 3 : On creer une classe qui derive de list + on garde une référence vers l'instance parent class MyList2(list): def __init__(self, alist): self._list = alist super().__init__(self._list)   def to_nparray(self): return np.array(self._list)   def to_tuple(self): return tuple(self._list)   #### Option 4 : On creer une classe qui derive de list et qui surcharge __getitem__ class MyList3(list): def __getitem__(self,idx): return list.__getitem__(self,idx)   data1 = MyList(data) data2 = MyList2(data) data3 = MyList3(data)   Niter4access = int(1e7) Niter4nparr_cast= int(1e4)   t0 = time() for i in range(Niter4access) : b=data[i%datasize] t1 = time() for i in range(Niter4access) : b=data1[i%datasize] t2 = time() for i in range(Niter4nparr_cast) : b=to_nparray(data) t3 = time() for i in range(Niter4nparr_cast) : b=data1.to_nparray() t4 = time() for i in range(Niter4nparr_cast) : b=to_tuple(data) t5 = time() for i in range(Niter4nparr_cast) : b=data1.to_tuple() t6 = time() for i in range(Niter4access) : b=data3[i%datasize] t7 = time() for i in range(Niter4access) : b=data2[i%datasize] t8 = time() for i in range(Niter4nparr_cast) : b=data2.to_tuple() t9 = time() for i in range(Niter4nparr_cast) : b=data2.to_nparray() t10 = time() for i in range(Niter4access) : b=data2._list[i%datasize] t11 = time()     print("======== Exec time ========") print("-- Particular acces (%s iter) ---"%Niter4access) print("External fct: %s"%(t1-t0)) print("Class1 method: %s"%(t2-t1)) print("Class2 method: %s"%(t8-t7)) print("Overwrite __getitem__: %s"%(t7-t6)) print("Class2 public attribute : %s"%(t11-t10)) print("-- np.array cast (%s iter) ---"%Niter4nparr_cast) print("External fct: %s"%(t3-t2)) print("Class1 method: %s"%(t4-t3)) print("Class2 method: %s"%(t10-t9)) print("-- tuple cast (%s iter) ---"%Niter4nparr_cast) print("External fct: %s"%(t5-t4)) print("Class1 method: %s"%(t6-t5)) print("Class2 method: %s"%(t9-t8))

---

qui produit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

======== Exec time ======== -- Particular acces (10000000 iter) --- External fct: 1.5130739212036133 Class1 method: 2.4333972930908203 Class2 method: 2.4490203857421875 Overwrite __getitem__: 4.981260776519775 Class2 public attribute : 1.793931007385254 -- np.array cast (10000 iter) --- External fct: 5.459544897079468 Class1 method: 6.6294474601745605 Class2 method: 5.490988731384277 -- tuple cast (10000 iter) --- External fct: 0.2807767391204834 Class1 method: 0.4795725345611572 Class2 method: 0.26518988609313965

---

Citation:

---

Envoyé par lg_53

La faute à numpy ? Bonne idée mais je viens de faire un test qui écarte cette hypothèse. Si dans mes classes je rajoutes des méthodes

Code:

---

1 2 3

class MyList(list): def to_tuple(self): return tuple(self)

---

On obtient aussi des écarts de temps considérables !

---

Voilà le test que j'ai chez moi:

Code:

---

1 2 3 4 5 6

**tuple** func: 0.052156925201416016 meth: 0.05215787887573242 **array** func: 1.0822701454162598 meth: 1.3430578708648682

---

et le code:

Code:

---

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

from time import time import numpy as np import gc gc.disable()   datasize = 2000 rd = np.random.RandomState(seed=0) data = list( rd.rand(datasize) )   def to_target(alist, target): return target(alist)   class A(list): def to_target(self, target): return target(self)   data2 = A(data.copy())   count = 10000   def test(target): t0 = time() for _ in range(count): z = to_target(data, target)   t1 = time() c = data2.to_target for _ in range(count): z = c(target)   t2 = time()   print ('**%s**' % target.__name__) print ('func:', t1 - t0) print ('meth:', t2 - t1)   test(tuple) test(np.array)

---

Difficile de conclure autre chose côté numpy. Désolé!
Et j'aurais bien aimé avoir des différences significatives avec "tuple" : les sources sont beaucoup plus faciles à lire.


- W

Et bien ça alors !

Voici ce que j'obtiens moi lorsque j'éxécute ton code :

Code:

---

1 2 3 4 5 6

**tuple** func: 0.0467989444732666 meth: 0.0935983657836914 **array** func: 1.0919790267944336 meth: 1.325974464416504

---

Donc pour l'array, on est raccord, mais pour le tuple là ... Ca me laisse perplexe tout ça.
Tu utilises quelle version de Python ?

Voici mon install, sous Windows 7 :

Code:

---

1 2	In [13]: sys.version Out[13]: '3.5.4 |Anaconda custom (64-bit)| (default, Nov 8 2017, 14:34:30) [MSC v.1900 64 bit (AMD64)]'

---

Citation:

---

Envoyé par lg_53

Donc pour l'array, on est raccord, mais pour le tuple là ... Ca me laisse perplexe tout ça.
Tu utilises quelle version de Python ?

---

3.4, 3.6, ...
Après avoir rejoué avec ces tests, il y a une certaine variabilité dans le résultat (plusieurs exécution sortent des durées différentes). Je suspecte que la durée est trop petite pour ne pas être sensible aux bruits (d'autres activités systèmes).
Tout cela est à retravailler.

- W

Certes il y a de la variabilité un peu sur les temps d'éxcution, mais même en augmentant le nombres d'itérations, je constate tout de même un écart significatif qui ne peut pas juste être du à de la variabilité.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

>>>count = 1000000   >>>test(tuple) **tuple** func: 4.63319993019104 meth: 9.687599897384644   >>>test(tuple) **tuple** func: 4.617599964141846 meth: 9.656399965286255   >>>test(tuple) **tuple** func: 4.617599964141846 meth: 9.674599885940552

---

Ca donne quoi de ton côté sur ta machine si tu augmentes le nombre d'itérations ?

Selon certain besoin, on pourrait changer par exemple ta classe MyList2 comme ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class MyList2(list): def __init__(self, alist): self._list = np.asarray(alist) super().__init__(self._list)   def to_nparray(self): return self._list   def __setitem__(self,key,item): self._list[key] = item super().__setitem__(key,item)   def to_tuple(self): return tuple(super().__iter__())

---

ce qui donnerait:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

======== Exec time ======== -- Particular acces (10000000 iter) --- External fct: 1.6983397006988525 Class1 method: 2.6795356273651123 Class2 method: 2.7235448360443115 Overwrite __getitem__: 4.983496427536011 Class2 public attribute : 2.673534631729126 -- np.array cast (10000 iter) --- External fct: 6.017703533172607 Class1 method: 7.474494457244873 Class2 method: 0.0020003318786621094 -- tuple cast (10000 iter) --- External fct: 0.28905773162841797 Class1 method: 0.5576114654541016 Class2 method: 0.5656130313873291

---

Mais bon, comme je dis, c'est selon le besoin car ici, on crée le array numpy tout en conservant la "list" (on utilise donc plus de mémoire) ...
D'où le besoin de redéfinir la méthode __setitem__ pour modifier le array quant on modifie la "list".

Pour ton histoire de tuple, je suis toujours sur les temps qu'il y a ci-dessus, chez moi ça à l'air constant (je suis en 3.6).

Oui effectivement c'est selon les besoins cette solution. Malheureusement pour moi ce n'est pas envisgeable dans mon cas : les listes sont grosses, et on a besoin souvent d'y faire des append, donc s'il faut faire des np.concatenate sur l'array derrière à chaque append sur la liste, laisse tomber le cout !

Pour ce qui est du cast vers un tuple tu constates aussi la différence de coût entre la fonction externe, et les méthodes internes à des classes.

Merci pour votre aide à tous en tout cas et les solutions proposées. Je vais passer le topic en résolu, choisissant l'option 1 dans mon premier post, bien que la question du pourquoi ce surcoût, même dans le cas d'un cast vers un tuple, reste finalement en suspens (surcoût qui ne semble pas être constaté chez tous le monde d'ailleurs...).

Salut,

J'ai compris ce qui me choquait dans ces tests.

La liste peut être native ou s/classée "tuple" ou "nd.array" vont itérer sur chacun des éléments de cette liste. Python retournera une référence à l'objet qui sera stocké ou recopié suivant le cas.
Il y a en gros deux étapes: la création du contexte de la boucle qui va faire les accès et l'accès aux éléments.... Et si je prend une grosse liste ou N plus petites, je biaise le résultat dans un sens ou dans l'autre en fonction de la taille de la liste et du nombre d'itérations (des appels à la fonction qui... histoire d'avoir une durée acceptable).
Donc il faut fixer les choses pour qu'à la fin on ait créé le même nombre d'accès.
i.e #itération * #elements doit être +/- constant.
Ce qui donne ce code:

Code:

---

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

from time import process_time as time import numpy as np import gc   def access(alist, target=None): for e in alist: z = e   def create(alist, target): return target(alist)   def create2(alist, target=None): return np.fromiter(alist, dtype=int)   class A(list): create = create access = access create2 = create2   power = 7 samples = 10**power   def test(cname, klass, target=None): for x in range(power): count = 10**x size = int(samples / count) assert size * count == samples   #count = 10 * count data = list(range(size)) a = klass(data)   func = globals().get(cname) meth = getattr(a, cname)   gc.disable() t0 = time() for _ in range(count): func(data, target) t1 = time()   for _ in range(count): meth(target) t2 = time() gc.enable() print('*** func: %.5f, meth: %.5f' %(t1 - t0, t2 - t1), 'size: ', size, 'count: ', count)

---

Avec test('access', A), on voit que les accès via la fonction ou la méthode prennent à peu près le même temps:

Code:

---

1 2 3 4 5 6 7 8

*** func: 0.15625, meth: 0.17188 size: 10000000 count: 1 *** func: 0.15625, meth: 0.17188 size: 1000000 count: 10 *** func: 0.15625, meth: 0.15625 size: 100000 count: 100 *** func: 0.15625, meth: 0.15625 size: 10000 count: 1000 *** func: 0.17188, meth: 0.15625 size: 1000 count: 10000 *** func: 0.18750, meth: 0.17188 size: 100 count: 100000 *** func: 0.29688, meth: 0.29688 size: 10 count: 1000000

---

Avec test('create', A, tuple), çà varie dans les deux sens suivant la valeur du nombre d'itérations et du nombre d’éléments (et çà va généralement plus vite que le code précédent car çà bosse essentiellement dans le code C):

Code:

---

1 2 3 4 5 6 7

*** func: 0.40625, meth: 0.25000 size: 10000000 count: 1 *** func: 0.17188, meth: 0.17188 size: 1000000 count: 10 *** func: 0.04688, meth: 0.06250 size: 100000 count: 100 *** func: 0.07812, meth: 0.04688 size: 10000 count: 1000 *** func: 0.04688, meth: 0.03125 size: 1000 count: 10000 *** func: 0.04688, meth: 0.06250 size: 100 count: 100000 *** func: 0.21875, meth: 0.26562 size: 10 count: 1000000

---

Avec np.array test('create', A, np.array), j'ai une anomalie:

Code:

---

1 2 3 4 5 6 7

*** func: 0.54688, meth: 1.09375 size: 10000000 count: 1 *** func: 0.53125, meth: 1.00000 size: 1000000 count: 10 *** func: 0.50000, meth: 0.87500 size: 100000 count: 100 *** func: 0.48438, meth: 0.62500 size: 10000 count: 1000 *** func: 0.48438, meth: 0.64062 size: 1000 count: 10000 *** func: 0.53125, meth: 0.96875 size: 100 count: 100000 *** func: 1.21875, meth: 4.29688 size: 10 count: 1000000

---

car le passage par méthode coûte bien plus que dans le cas tuple.
Le problème est illustré par:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

>>> import numpy as np >>> L = [1, 2, 3] >>> class A(list): ... def __iter__(self): ... print('__iter__') ... return super().__iter__() ... >>> np.array(A(L)) __iter__ __iter__ __iter__ array([1, 2, 3]) >>> tuple(A(L)) __iter__ (1, 2, 3) >>>

---

i.e. np.array s'assure qu'on ne lui a pas passé un tableau de tableaux... Et çà coûte un bras. test('create2', A) dit à numpy de ne pas s'en embarrasser (via np.fromiter):

Code:

---

1 2 3 4 5 6 7

*** func: 0.39062, meth: 0.35938 size: 10000000 count: 1 *** func: 0.31250, meth: 0.32812 size: 1000000 count: 10 *** func: 0.21875, meth: 0.21875 size: 100000 count: 100 *** func: 0.21875, meth: 0.21875 size: 10000 count: 1000 *** func: 0.25000, meth: 0.23438 size: 1000 count: 10000 *** func: 0.35938, meth: 0.34375 size: 100 count: 100000 *** func: 1.15625, meth: 1.17188 size: 10 count: 1000000

---

Et d'obtenir des résultats bien meilleurs.

- W

Salut

Merci beaucoup pour cette réponse très complète et bien détaillée.

Citation:

---

Envoyé par wiztricks

Avec test('create', A, tuple), çà varie dans les deux sens suivant la valeur du nombre d'itérations et du nombre d’éléments (et çà va généralement plus vite que le code précédent car çà bosse essentiellement dans le code C):

Code:

---

1 2 3 4 5 6 7

*** func: 0.40625, meth: 0.25000 size: 10000000 count: 1 *** func: 0.17188, meth: 0.17188 size: 1000000 count: 10 *** func: 0.04688, meth: 0.06250 size: 100000 count: 100 *** func: 0.07812, meth: 0.04688 size: 10000 count: 1000 *** func: 0.04688, meth: 0.03125 size: 1000 count: 10000 *** func: 0.04688, meth: 0.06250 size: 100 count: 100000 *** func: 0.21875, meth: 0.26562 size: 10 count: 1000000

---

---

Je veux bien qu'on s'arrange pour faire des comparaisons de telles sortes que #itération * #elements doit être +/- constant, mais il faut quand même que le temps d'éxécution à la sortie soit suffisamment significatif pour ne pas être trop sensible à des phénomènes extérieurs. Car dire que tantot la méthode est plus rapide, tantot c'est la fonction ca me parait un peu suspect.

J'ai donc enquêté et j'ai fais mes tests en relancant ton code, avec power=8 et en y ajoutant dans le print le différentiel en bout de ligne. test('create', A, tuple) donne :

Code:

---

1 2 3 4 5 6 7 8

*** func: 1.15440, meth: 1.20120 size: 100000000 count: 1 delta: +4.05% *** func: 1.17000, meth: 1.20120 size: 10000000 count: 10 delta: +2.67% *** func: 1.13880, meth: 1.17000 size: 1000000 count: 100 delta: +2.74% *** func: 0.39000, meth: 0.56160 size: 100000 count: 1000 delta: +44.00% *** func: 0.31200, meth: 0.51480 size: 10000 count: 10000 delta: +65.00% *** func: 0.23400, meth: 0.49920 size: 1000 count: 100000 delta: +113.33% *** func: 0.43680, meth: 0.76440 size: 100 count: 1000000 delta: +75.00% *** func: 2.12160, meth: 2.77680 size: 10 count: 10000000 delta: +30.88%

---

J'ai lancé 10 fois la chose j'obtiens toujours dans le même ordre de grandeur : la fonction est toujours plus performante que la méthode (contrairement à ce que tu as pu constater en faisant 10 fois moins d'itérations avec power = 7). Sur de très gros tableaux ca ne semble pas être énorme (2 à 4%). Mais sur des tableaux de taille inférieure ou égal à 100 000 éléments, là ça déconne. Dans le code que je proposais au tout début, j'avais fixé mon dataset à 10 000. Si je regarde la ligne en question ici pour un dataset de taille 10 000, on y est sur des écarts signifiactifs...


Par contre, sur l'aspect que numpy fait des vérifications et donc explose son temps d'exe à cause de cela là c'est super bien vu ça.

Citation:

---

Envoyé par wiztricks

Avec np.array test('create', A, np.array), j'ai une anomalie:

Code:

---

1 2 3 4 5 6 7

*** func: 0.54688, meth: 1.09375 size: 10000000 count: 1 *** func: 0.53125, meth: 1.00000 size: 1000000 count: 10 *** func: 0.50000, meth: 0.87500 size: 100000 count: 100 *** func: 0.48438, meth: 0.62500 size: 10000 count: 1000 *** func: 0.48438, meth: 0.64062 size: 1000 count: 10000 *** func: 0.53125, meth: 0.96875 size: 100 count: 100000 *** func: 1.21875, meth: 4.29688 size: 10 count: 1000000

---

car le passage par méthode coûte bien plus que dans le cas tuple.
Le problème est illustré par:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

>>> import numpy as np >>> L = [1, 2, 3] >>> class A(list): ... def __iter__(self): ... print('__iter__') ... return super().__iter__() ... >>> np.array(A(L)) __iter__ __iter__ __iter__ array([1, 2, 3]) >>> tuple(A(L)) __iter__ (1, 2, 3) >>>

---

---

Même odre de grandeur lorsque j'éxécute chez moi. Gros point pour toi wiztricks, j'étais clairement passé à côté de cela. Ca ca montre pourquoi c'est plus gourmand de caster vers un np.array que vers un tuple. Mais ca n'explique pas les écarts constaté juste avant entre fonction et méthode.

Je poursuit mon enquête et me dit finalement qu'on avait contourner le problème déjà (sans comprendre pourquoi) avec la classe qui gardait une référence

Code:

---

1 2 3 4 5 6 7 8 9 10

class MyList2(list): def __init__(self, alist): self._list = alist super().__init__(self._list)   def to_nparray(self): return np.array(self._list)   def to_tuple(self): return tuple(self._list)

---

à la liste originelle. Et la raison finalement c'est que là en passant par cette référence, on passait donc à notre constructeur numpy directement un type de base. Le code ci dessous l'illustre bien (même si on se limite au cas où les données sont de taille fixée à 10 000)

Code:

---

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

import numpy as np from time import time   #### Sujet developpez.net relie à ce code : ### https://www.developpez.net/forums/d1861888/autres-langages/python-zope/calcul-scientifique/benchmark-conversion-list-numpy-array/   datasize=10000   rd = np.random.RandomState(seed=0) data = list( rd.rand(datasize) )     def to_nparray(datalist): return np.array(datalist)   def to_tuple(datalist): return tuple(datalist)   class MyList(list): def __init__(self, alist): self._list = alist super().__init__(self._list)   def to_nparray1(self): return np.array(self._list)   def to_nparray2(self): return np.array(self)   def to_nparray3(self): return np.fromiter(self, dtype=float)   def to_nparray4(self): return np.fromiter(self._list, dtype=float)   def to_tuple1(self): return tuple(self._list)   def to_tuple2(self): return tuple(self)     data1 = MyList(data)   def test_func(fname, data): func = globals().get(fname) t0 = time() for _ in range(Niter): a=func(data) t1 = time() print('func %20s : %s'%(fname+'('+d.__class__.__name__+')',t1-t0))   def test_meth(mname): meth = getattr(data1, mname) t0 = time() for _ in range(Niter): a=meth() t1 = time() print('meth %20s : %s'%(mname,t1-t0))     Niter = int(2e4)   print('-- *** cast tuple *** --') for d in (data, data1): test_func('to_tuple',d) for i in range(1,3): test_meth('to_tuple'+str(i))   print('-- *** cast np_array *** --') for d in (data, data1): test_func('to_nparray', d) for i in range(1,5): test_meth('to_nparray'+str(i))

---

qui donne

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

-- *** cast tuple *** -- func to_tuple(list) : 0.5616037845611572 func to_tuple(MyList) : 0.9828062057495117 meth to_tuple1 : 0.5514054298400879 meth to_tuple2 : 0.9828064441680908 -- *** cast np_array *** -- func to_nparray(list) : 10.780669212341309 func to_nparray(MyList) : 13.02608346939087 meth to_nparray1 : 10.810869216918945 meth to_nparray2 : 13.010483503341675 meth to_nparray3 : 2.4492156505584717 meth to_nparray4 : 2.464815855026245

---

Et là effectivement on voit également bien que :
- la fonction to_tuple(list) et la méthode to_tuple1 produise le même temps : elles s'appuient toutes deux sur le type natif qu'est la liste
- même temps aussi pour to_tuple(MyList) et la méthode to_tuple2, qui s'appui directement sur un input de type MyList non natif
- les 2 précédentes remarques sont également constatées dans le cadre d'un cast vers un numpy array
- les 2 méthodes s'appuyant sur np.fromiter sont comparables indépendamment du type d'entrée

Conclusion :
- Méthode et fonction sont donc comparables. C'est le type d'input qui fait donc la différence (selon s'il est natif ou non). Pour garder l'équivalence sur les temps d'exe il faut donc garder une référence à l'instance parent de type natif
- La méthode np.fromiter permet de s'affranchir de tout cela lorsqu'on cast vers un array puisque considère l'objet passé, quelqu'il soit, comme un itérateur.


Me reste à vérifier tout ceci sur les méthodes d'accès particulaires. Je ferais un autre poste lundi pour ce point.
Un super gros merci en tout cas aux contributeurs de ce topic, et à wiztricks tout particulièrement

Bon weekend

Je sors un peu du sujet, mais il ne te serait pas possible de rester en array numpy au lieu de passer de l'un à l'autre ?

Sinon, l'inverse ne serait pas moins coûteux: de array numpy vers une liste (bien sur, si tu peux voir ton problème dans ce sens là) ?

Salut,

Citation:

---

Envoyé par lg_53

Je veux bien qu'on s'arrange pour faire des comparaisons de telles sortes que #itération * #elements doit être +/- constant, mais il faut quand même que le temps d'éxécution à la sortie soit suffisamment significatif pour ne pas être trop sensible à des phénomènes extérieurs. Car dire que tantot la méthode est plus rapide, tantot c'est la fonction ca me parait un peu suspect.

---

Ca dépend ce qu'on cherche.

Pour moi, pourvu qu'on aide un peu Python, l'appel à la méthode n'est pas moins rapide que l'appel à la fonction (c'est ce que raconte le premier test). Par contre, il y a des différences entre type natif et s/classe. Essentiellement parce que vérifier que la méthode n'est pas dans le dict de la classe utilisateur avant de récupérer l'adresse d'une fonction via l'offset d'un struct C coûte (et çà, pas de magie pour l'optimiser autre que l'accès direct au type natif...).

Et donc c'est sûr que plein d'itérations vs une liste à un élément va exploser les compteurs.
note: c'est d'ailleurs pour çà que je ne teste même pas côté "méthodes d'accès particulaires", on se paie l'overhead de la mécanique pour ramener une seule référence.

Mon propos était juste de montrer que np.array avait un (sur)coût démesuré comparé à tuple et que ce coût dépendait de la taille de la liste. Suite à quoi, çà motive d'aller voir dans la documentation pour voir s'il n'y a pas mieux et y trouver np.fromiter.
note: pour voir çà dans les tests, il suffit de regarder les lignes où on a de grandes listes et peu d'itérations. Avec tuple la s/classe est semblable au type natif alors qu'avec np.array, on est déjà dans les choux.

- W

Suite de la saga : benchmark sur l'accès particulaire.

Le code suivant:

Code:

---

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

import numpy as np from time import time   class MyList(list): def __init__(self, alist): self._list = alist super().__init__(self._list)   def get1(self, i): return self[i]   def get2(self, i): return self._list[i]   def test_getitem(data): cname = data.__class__.__name__ N = len(data) meth = data.__getitem__   t0 = time() for i in range(Niter): a=meth(i%N) t1 = time() print('%20s : %s'%(cname+'.meth',t1-t0))   t0 = time() for i in range(Niter): a=data.__getitem__(i%N) t1 = time() print('%20s : %s'%(cname+'.__getitem__',t1-t0))   t0 = time() for i in range(Niter): a=data[i%N] t1 = time() print('%20s : %s'%(cname+'[]',t1-t0))     def test_meth(mname): meth = getattr(data_mylist, mname) N = len(data_mylist) t0 = time() for i in range(Niter): a=meth(i%N) t1 = time() print('%20s : %s'%(data_mylist.__class__.__name__+'.'+mname,t1-t0))     Niter_times_datasize_power = 10   for i in range(1,Niter_times_datasize_power+1): datasize=10**i Niter = 10**(Niter_times_datasize_power-i)   rd = np.random.RandomState(seed=0) data_list = list( rd.rand(datasize) ) data_tuple = tuple( data_list ) data_array = np.fromiter(data_list) data_mylist = MyList(data_list)   print('----- datasize : %d Niter : %d ----'%(datasize, Niter)) test_getitem(data_array) test_getitem(data_tuple) test_getitem(data_list) test_getitem(data_mylist) test_meth('get1') test_meth('get2')

---

donne

Code:

---

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 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

----- datasize : 10 Niter : 1000000000 ---- ndarray.meth : 143.34151816368103 ndarray.__getitem__ : 185.50509357452393 ndarray[] : 106.11187410354614 tuple.meth : 88.44966983795166 tuple.__getitem__ : 130.1745092868805 tuple[] : 51.49375867843628 list.meth : 67.41389679908752 list.__getitem__ : 93.03752303123474 list[] : 51.750850200653076 MyList.meth : 67.34592080116272 MyList.__getitem__ : 114.10770392417908 MyList[] : 141.90324783325195 MyList.get1 : 195.3817093372345 MyList.get2 : 134.57937955856323 ----- datasize : 100 Niter : 100000000 ---- ndarray.meth : 14.473280668258667 ndarray.__getitem__ : 18.68649458885193 ndarray[] : 10.70017385482788 tuple.meth : 8.858410835266113 tuple.__getitem__ : 13.042917490005493 tuple[] : 5.4585113525390625 list.meth : 6.749993085861206 list.__getitem__ : 9.307555675506592 list[] : 5.1195068359375 MyList.meth : 6.754076242446899 MyList.__getitem__ : 11.410252094268799 MyList[] : 14.864243030548096 MyList.get1 : 20.506871700286865 MyList.get2 : 13.664382457733154 ----- datasize : 1000 Niter : 10000000 ---- ndarray.meth : 1.4823944568634033 ndarray.__getitem__ : 1.9026758670806885 ndarray[] : 1.11826753616333 tuple.meth : 0.9546623229980469 tuple.__getitem__ : 1.3584046363830566 tuple[] : 0.583106517791748 list.meth : 0.7552444934844971 list.__getitem__ : 1.000119924545288 list[] : 0.5671353340148926 MyList.meth : 0.7554869651794434 MyList.__getitem__ : 1.206751823425293 MyList[] : 1.5009753704071045 MyList.get1 : 2.0428097248077393 MyList.get2 : 1.4099791049957275 ----- datasize : 10000 Niter : 1000000 ---- ndarray.meth : 0.15135693550109863 ndarray.__getitem__ : 0.2037186622619629 ndarray[] : 0.11478161811828613 tuple.meth : 0.09796690940856934 tuple.__getitem__ : 0.13777518272399902 tuple[] : 0.06052851676940918 list.meth : 0.07859516143798828 list.__getitem__ : 0.10262942314147949 list[] : 0.059446096420288086 MyList.meth : 0.07865047454833984 MyList.__getitem__ : 0.12306332588195801 MyList[] : 0.15300321578979492 MyList.get1 : 0.20720958709716797 MyList.get2 : 0.1430516242980957 ----- datasize : 100000 Niter : 100000 ---- ndarray.meth : 0.015029430389404297 ndarray.__getitem__ : 0.019211292266845703 ndarray[] : 0.01141667366027832 tuple.meth : 0.009816646575927734 tuple.__getitem__ : 0.013797760009765625 tuple[] : 0.0061130523681640625 list.meth : 0.007891416549682617 list.__getitem__ : 0.010290145874023438 list[] : 0.005977630615234375 MyList.meth : 0.007889032363891602 MyList.__getitem__ : 0.012327194213867188 MyList[] : 0.01532435417175293 MyList.get1 : 0.02076435089111328 MyList.get2 : 0.01433253288269043 ----- datasize : 1000000 Niter : 10000 ---- ndarray.meth : 0.0015451908111572266 ndarray.__getitem__ : 0.002026081085205078 ndarray[] : 0.001146078109741211 tuple.meth : 0.0010075569152832031 tuple.__getitem__ : 0.0013790130615234375 tuple[] : 0.0006091594696044922 list.meth : 0.0007991790771484375 list.__getitem__ : 0.0010249614715576172 list[] : 0.0005877017974853516 MyList.meth : 0.0007872581481933594 MyList.__getitem__ : 0.0012302398681640625 MyList[] : 0.0015330314636230469 MyList.get1 : 0.0020728111267089844 MyList.get2 : 0.0014333724975585938 ----- datasize : 10000000 Niter : 1000 ---- ndarray.meth : 0.00016045570373535156 ndarray.__getitem__ : 0.0001933574676513672 ndarray[] : 0.00011038780212402344 tuple.meth : 9.679794311523438e-05 tuple.__getitem__ : 0.00013375282287597656 tuple[] : 5.602836608886719e-05 list.meth : 7.367134094238281e-05 list.__getitem__ : 9.822845458984375e-05 list[] : 5.507469177246094e-05 MyList.meth : 7.510185241699219e-05 MyList.__getitem__ : 0.00011873245239257812 MyList[] : 0.0001533031463623047 MyList.get1 : 0.000202178955078125 MyList.get2 : 0.00013899803161621094

---

NB: les .meth, c'est __getitem__ mais avec la méthode stocké avant pour éviter la recherche dans le dico.

- Pour les types natifs (tuple et liste), écrire data[] est plus rapide que de factoriser la méthode __getitem__ pour l'appeler ensuite. Faire des appels simple à __getitem__ (sans factoriser la méthode au préalable) coute relativement chère : Comme la fait précédemment remarqué wiztricks, la recherche de la méthode dans le dictionnaire de la classe coûte chère : ca multiplie par 2 ici le temps d'exe !

- Liste semble un peu plus rapide que tuple (je me serais attendu à l'inverse vu que tuple est de taille fixé, j'aurais pensé que ce serait plus optimisé...)

- Pour le type numpy, écrire data[] est aussi ce qu'il y a de plus rapide. Quelquesoit le cas de figure c'est environ 2 fois plus lent que sur un tuple.

- Pour une sous-classe de liste, contrairement aux autres, le plus rapide est l'appel à __getitem__ (que l'on factorise). Cette méthode est équivalente en temps sur une instance de liste, ou bien sur une instance d'une sous classe de liste.

Si on dérive la classe liste, l'accès particulaire :
- oblige à factoriser la méthode __getitem__ avant son appel pour être optimal
- coûte environ 30% de plus qu'un classique data_list[]

Ca fait cher la sous classe. Je vais rester du coup sur des méthodes extérieures to_nparray pour ne pas non plus avoir à payer aussi le surcoût d'une sous-classe de côté là.

Citation:

---

Envoyé par disedorgue

Je sors un peu du sujet, mais il ne te serait pas possible de rester en array numpy au lieu de passer de l'un à l'autre ?

Sinon, l'inverse ne serait pas moins coûteux: de array numpy vers une liste (bien sur, si tu peux voir ton problème dans ce sens là) ?

---

Dans mon cas ca serait l'inverse i.e. de rester en liste sans passer par des arrays numpy. Mais bon ce sont des grosses listes, et après je dois les sortir dans des fichiers. Je dois donc benchmarké ca aussi : écrire une liste dans un fichier VS conversion liste-->numpy et faire écrire à numpy dans le fichier. J'avais lu que numpy était assez optimiser pour ça. Je vais donc vérifier ça, et voir si ca vaut encore le coût même s'il faut se payer un cast avant...
Ca fera peut-être l'objet d'un nouveau topic.

Merci à vous tous