Optimisation

[krunch]

C'est bien vos défis, perso j'arrive toujours un peu trop tard (ou trop la flegme c'est vrai).

 

J'aurais une question sur l'optimisation, dans le fil de ce fil... http:// http://www.cadxp.com/sujetXForum-15170.htm http:// et plus particulièrement de ce que dit Didier-AD sur les unités de temps qui est très pédago : il y a cons, append, reverse.. Et les autres ? (assoc, member, mapcar..) . Et surtout les vl- comme vl-remove, qui sont bien pratiques ?

A vous lire j'ai peur en les utilisant de tomber dans l'absence totale d'élégance.. dans le plouccisme absolu..

[Didier-AD]

Merci du compliment

 

les fonctions ASSOC, MEMBER, MAPCAR n'ont pas les mêmes roles ; il n'est donc pas aisé de les comparer d'un point de vue optimisation

 

ASSOC permet de trouver une sous liste par l'intermédiaire d'une cle (numérique ou chaine) dans une liste en arbre du type

 

(setq l '((1 "Didier" "BTP") (2 "Krunch" "Meca") (3 "BonusCAD" "GIS")))

 

(assoc 2 l) retourne (2 "Krunch" "Meca")

 

le temps d'exécution dépend de la position de la sousliste dans la liste principale ; au pire, on peut compter n unité de temps (n = nombre de sous listes dans la liste) : pour descendre jusqu'à la clé

 

MEMBER permet souvent de tester l'existence d'un élément dans une liste mais aussi de rtourner la fin d'une liste à partir de cet élément ;

 

(setq l '(1 2 3 4 5 6 7 8 9))

(member 5 l ) retourne (5 6 7 8 9)

 

le temps d'exécution est du même ordre que celui de assoc il dépend de la position de l'élément dans la liste ; au pire n unité de temps (avec n le nombre d'éléments de la liste)

 

MAPCAR sert à appliquer une fonction à tous les éléments d'une ou plusieurs listes et retourne la liste des résultats.

il me semble que giles (ou Patrick_35) a écrit un "papier très instructif sur MAPCAR dans le fil d'un récent challenge mais je ne l'ai pas retrouvé pour mettre un lien dessus

 

MAPCAR exécute la fonction demandée autant de fois qu'il y a d'élément dans la plus courte des listes qui lui sont proposées le temps d'exécution dépend bien entendu de la fonction à exécuter

à titre personnel, je voue à MAPCAR une véritable dévotion car elle est d'une puissance fabuleuse dans le traitement des listes.

 

FOREACH permet d'exécuter n fois (n = nombre d'éléments d'une liste) un série d'instructions ou une fonction ; le temps d'exécution dépend des instructions ou de la fonction à exécuter

à la différence de MAPCAR, FOREACH retourne ce qu'a retourné la dernière instruction exécutée et non pas une liste

 

Quand aux fonctions vl-*, elles ont chacune leur utilité , soit pour ne garder que certaines valeur d'une liste soit pour vérifier des propriétés des éléments d'une liste

elles sont toutes associées à une fonction dont le role est de retourner T ou NIL

le temps d'exécution de ces fonctions VL dépend essentiellement du temps d'exécution de la fonction associée qui est répétée en général n fois (n étant le nombre d'éléments de la liste).

 

Encore une fois, il est difficile de comparer ces différentes fonctions car elles ont des rôles différents, ce que je peux te conseiller c'est de les essayer chacune avec des exemples simples afin de bien comprendre ce qu'elles fournissent et à partir de quoi ; et lorsque l'occasion se présentera tu pourras choisir celle qui te convient le mieux

 

VLISP et c'est sa force permet d'obtenir les mêmes résultats avec des écritures différentes,

Finalement, le temps d'exécution n'a d'importance que quand les calculs sont très répétitifs,

La concision du code fait souvent frémir de bonheur les vieux lispeurs, mais je t'avoue que parfois lorsque je relis mes anciens codes avec 3 mapcar dans la même ligne, je regrette de ne pas avoir pris le temps de mettre quelques commentaires..

 

 

 

 

 

 

[Edité le 28/5/2007 par Didier-AD]

[(gile)]

Salut,

 

pour mapcar, c'est ici et la suite là

 

Si tu chasse la milliseconde, tu peux utiliser ce benchmark pour comparer des routines ou expressions équivalentes.

[krunch]

OK, donc si je tente un récap malgré tout (malgré que ce soit très approximatif ) ça donnerait qq-chose comme ça..

(d'autre part il n'y a pas de contrindication particulière contre les vl-*)

 

N = nombre d'éléments de la liste fourni

I = position de la 1ère occurence de l'élément recherché / vérifiant un test (I <= N)

 

 

cons 1

 

append N+1

 

reverse 2N

 

assoc I

member

vl-position

 

mapcar N + N x (fonctions imbriqués)

foreach

vl-remove

vl-remove-if

vl-remove-if-not

vl-some

vl-sort

vl-sort-i

 

vl-member-if I + I x (fonctions imbriqués)

vl-member-if-not

 

 

[Didier-AD]

en gros, c'est çà

 

[Didier-AD]

Si tu chasse la milliseconde, tu peux utiliser ce benchmark pour comparer des routines ou expressions équivalentes.

 

merci

[Patrick_35]

Si tu chasse la milliseconde, tu peux utiliser ce benchmark pour comparer des routines ou expressions équivalentes.

 

Sauf qu'il donne des résultats surprenant

J'ai testé par curiosité laquel de ces deux méthodes est la plus rapide

 

(tblsearch "style" "romans")

et

(vla-item (vla-get-textstyles (vla-get-activedocument (vlax-get-acad-obect))) "romans")

Et bien, le plus rapide depend de l'humeur du lisp. Un coup autolisp, un coup le vlisp

Il suffit de lancer le même test 4 ou 5 fois et les résultats ne sont pas les mêmes :casstet:

J'ai même testé avec '((1+ 2) (+ 1 2) (+ 1.0 2) (+ 1.0 2.0) (+1 2.0)) juste pour voir et là aussi les résultats diffèrent :o

 

@+

[(gile)]

L'auteur du LISP (Michael Puckett) prévient que les résultats sont "dramatiquement affectés par les taches en fond".

 

Chez moi, si les résultatas ne sont pas rigoureusement identiques, je pense qu'il permettent quand même de se faire une idée :

 

_$ (benchmark

'((tblsearch "style" "standard")

(vla-item

(vla-get-textstyles

(vla-get-activedocument (vlax-get-acad-object))

)

"standard"

)

)

)

Benchmarking .................Elapsed milliseconds / relative speed for 16384 iteration(s):

 

(TBLSEARCH "style" "standard")...............1829 / 1.31

(vla-Item (vla-get-TextStyles (vla-g...).....2390 / 1.00

_$ (benchmark

'((tblsearch "style" "standard")

(vla-item

(vla-get-textstyles

(vla-get-activedocument (vlax-get-acad-object))

)

"standard"

)

)

)

Benchmarking .................Elapsed milliseconds / relative speed for 16384 iteration(s):

 

(TBLSEARCH "style" "standard")...............1844 / 1.29

(vla-Item (vla-get-TextStyles (vla-g...).....2375 / 1.00

_$ (benchmark

'((tblsearch "style" "standard")

(vla-item

(vla-get-textstyles

(vla-get-activedocument (vlax-get-acad-object))

)

"standard"

)

)

)

Benchmarking .................Elapsed milliseconds / relative speed for 16384 iteration(s):

 

(TBLSEARCH "style" "standard")...............1812 / 1.32

(vla-Item (vla-get-TextStyles (vla-g...).....2391 / 1.00

 

De toutes façons ces résultats sont à interpréter sans perdre de vue ce qu'ils représentent : la différence de résultat pour (+ 1 2) dans l'exemple ci dessous, est de 16 millisecondes pour 65536 itérations

 

_$ (benchmark '((1+ 2) (+ 1 2) (+ 1.0 2) (+ 1.0 2.0) (+ 1 2.0)))

Benchmarking ...................Elapsed milliseconds / relative speed for 65536 iteration(s):

 

(1+ 2)..........1766 / 1.05

(+ 1 2).........1828 / 1.02

(+ 1.0 2).......1859 / 1.00

(+ 1 2.0).......1859 / 1.00

(+ 1.0 2.0).....1860 / 1.00

_$ (benchmark '((1+ 2) (+ 1 2) (+ 1.0 2) (+ 1.0 2.0) (+ 1 2.0)))

Benchmarking ...................Elapsed milliseconds / relative speed for 65536 iteration(s):

 

(1+ 2)..........1765 / 1.05

(+ 1 2).........1812 / 1.03

(+ 1.0 2).......1844 / 1.01

(+ 1.0 2.0).....1859 / 1.00

(+ 1 2.0).......1860 / 1.00

[Patrick_35]

L'auteur du LISP (Michael Puckett) prévient que les résultats sont "dramatiquement affectés par les taches en fond".

Ah ok

 

J'avais ces résultats

 

(benchmark '((tblsearch "style" "romans")(vla-item (vla-get-textstyles (vla-get-activedocument (vlax-get-acad-object))) "romans")))

 

(TBLSEARCH "style" "romans").................1000 / 1.28

(vla-Item (vla-get-TextStyles (vla-g...).....1281 / 1

 

(TBLSEARCH "style" "romans").................1015 / 1.28

(vla-Item (vla-get-TextStyles (vla-g...).....1297 / 1

 

(TBLSEARCH "style" "romans").................1016 / 1.29

(vla-Item (vla-get-TextStyles (vla-g...).....1312 / 1

 

(TBLSEARCH "style" "romans").................1031 / 1.35

(vla-Item (vla-get-TextStyles (vla-g...).....1391 / 1

 

(defun a()(tblsearch "style" "romans"))

(defun b()(vla-item (vla-get-textstyles (vla-get-activedocument (vlax-get-acad-object))) "romans"))

(benchmark '(a b))

 

B.....1390 / 1

A.....1391 / 1

 

A.....1407 / 1.01

B.....1422 / 1

 

A.....1391 / 1

B.....1391 / 1

 

B.....1375 / 1.01

A.....1391 / 1

 

(benchmark '((1+ 2) (+ 1 2) (+ 1.0 2) (+ 1.0 2.0) (+ 1 2.0)))

 

(1+ 2)..........1453 / 1.05

(+ 1 2).........1500 / 1.02

(+ 1 2.0).......1515 / 1.01

(+ 1.0 2.0).....1516 / 1.01

(+ 1.0 2).......1531 / 1

 

(+ 1 2).........1515 / 1.06

(+ 1.0 2).......1531 / 1.05

(+ 1 2.0).......1546 / 1.04

(+ 1.0 2.0).....1547 / 1.04

(1+ 2)..........1610 / 1

 

(1+ 2)..........1500 / 1.04

(+ 1 2).........1500 / 1.04

(+ 1.0 2).......1546 / 1.01

(+ 1 2.0).......1562 / 1

(+ 1.0 2.0).....1563 / 1

 

(1+ 2)..........1469 / 1.07

(+ 1 2).........1516 / 1.04

(+ 1.0 2.0).....1531 / 1.03

(+ 1.0 2).......1547 / 1.02

(+ 1 2.0).......1579 / 1

 

Pas toujour facile de se faire une idée

 

@+

[(gile)]

(benchmark '(a b))

 

La syntaxe est plutôt (benchmark '((a) (b)))

 

(benchmark '(a b))

Benchmarking ......................Elapsed milliseconds / relative speed for [surligneur]524288 [/surligneur] iteration(s):

 

B.....1391 / 1.02

A.....1422 / 1.00

 

 

(benchmark '((a) (b)))

Benchmarking .................Elapsed milliseconds / relative speed for [surligneur]16384 [/surligneur] iteration(s):

 

(A).....1687 / 1.30

(B).....2187 / 1.00

[Patrick_35]

Mais c'est bien sure :cool:

J'étais surpris du résultat, mais sans chercher plus loin que le bout de ma souris

 

Bon, il me tarde de partir en vacance....

 

@+