Discussion :

[djibril]

Quelles sont les méthodes que vous utilisez pour optimiser au maximum vos scripts!!!!
Si vous avez des remarques, suggestions ou même liens internet vers des cours adéquats, tous les forumeurs pourraient en profiter 8) !!
Allez, à vos clavier!!!!!

[Jedai]

Globalement pour optimiser, rien ne vaut un bon algorithme.
Néanmoins, et surtout dans un langage aussi haut niveau que Perl, il y a un tas d'astuces qui permettent d'améliorer un peu la vitesse. Les pires perte de temps proviennent souvent de l'utilisation erronée des fonctionnalités avancées (un exemple qui me vient à l'esprit : utiliser sort() pour obtenir le max d'une liste).

Exemples simples d'optimisation : utiliser les placeholders et garder une connexion permanente à une base de donnée, utiliser les diverses optimisations de sort() lorsque le bloc de comparaison est relativement compliqué, etc...

Un très bon article (en anglais)

--
Jedaï

[djibril]

qu'entends tu par les placeholders ???

[djibril]

pas trop parlant ce thread .

Personne n'a d'astuces pour optimiser ces scripts :

- pas utiliser sort n'importe comment.
Rq : La fonction sort est très rapide et utilise un algorithme de tri évolué ecrit complètement en C, néanmoins, elle ne manipule que des listes tenant entièrement en mémoire (vive ou swap). ainsi évitez le tri d'enormes fichiers necessitant des fichiers temporaires et pour ceci il est vivement conseillé d'utiliser le module File::Sort
voici une doc de reference sur les tris en Perl.

- attention à l'utilisation des carcteres speciaux suivant $&, $`, $' dans les regex, car tres lent.

- utiliser les hash au max que des tableaux à plusieurs dimensions.
Les tableaux associatifs sont optimisés pour trouver la valeur d'une clé très rapidement.

- éviter qd c'est possible de faire des tonnes de boucles imbriquées

- utiliser des regex

- apparemment tr/0-9//; serait plus rapide que s/\d+//;

- le moyen le plus rapide d'accéder à la valeur du dernier index d'un tableau :
La valeur du dernier index d'un tableau est obtenue grâce à $#

- l'utilisation de map peut s'averer aussi interessant en temps d'execution

- optimisation page web

- etc
partagez vos astuces, decouvertes ou remarques qui pourraient aider tout le monde à améliorer et surtout optimiser son script.

NB: Je tiens tout de même à spécifier qu'il est toujours primordial d'avoir un bon algo avant tout of course 8)

[Arioch]

Perso, je n'entend pas le terme "optimisation" de la même manière que vous apparemment.

Dans mon boulot, le temps de traitement d'un script n'est pas d'une importance capitale et on ne chipote pas pour un script qui pourrait gagner 10 secondes en temps s'il était mieux organisé.

Par contre, ce que j'entend par optimisation chez moi consiste à relire l'ensemble du code, une fois le script achevé, et d'essayer de regrouper différents blocs ensemble pour éviter les redondances ou les trop nombreuses boucles foreach faisant chacune un traitement spécial mais toutes sur les mêmes données.

En clair, je code salement et passe la serpillère ensuite. Voilà mon optimisation.

[djibril]

Perso, je n'entend pas le terme "optimisation" de la même manière que vous apparemment.

Dans mon boulot, le temps de traitement d'un script n'est pas d'une importance capitale et on ne chipote pas pour un script qui pourrait gagner 10 secondes en temps s'il était mieux organisé.

Par contre, ce que j'entend par optimisation chez moi consiste à relire l'ensemble du code, une fois le script achevé, et d'essayer de regrouper différents blocs ensemble pour éviter les redondances ou les trop nombreuses boucles foreach faisant chacune un traitement spécial mais toutes sur les mêmes données.

En clair, je code salement et passe la serpillère ensuite. Voilà mon optimisation.

sacrée arioch , c'est clair que pour gagner 2s, c'est pas tres important. Mais bon, quand on est sur de gros projets et que les scripts tournent pendant des heures, 1heure ou plus de gagné n'est pas négligeable tout de même. Et puis, c'est toujours mieux de coder le plus proprement possible et garder de bonnes habitudes. A chacun sa façon de voir les choses!

[Arioch]

sacrée arioch

J'avoue, j'ai été terre à terre en lisant le terme "optimisation" mais si vous ne comptez ne parler que de l'optimisation du temps, autant modifier le titre du post it !

D'ailleurs, quand je relis mon camel book, on parle bien de plusieurs types d'optimisation... Pas seulement celui du temps...

Ok je connais la sortie

s/Arioch//;

[djibril]

si t'as une suggestion pour un meilleur titre, je suis preneur

[Jedai]

Le problème, dès que l'on parle d'optimisation, c'est qu'on a vite fait de dire des bétises, par exemple la phrase suivante est rarement vraie (les hashs ne sont pas aussi efficaces que les tableaux en général) :

- utiliser les hash au max que des tableaux à plusieurs dimensions.
Les tableaux associatifs sont optimisés pour trouver la valeur d'une clé très rapidement.

On a souvent des a priori sur la vitesse de telle ou telle partie de son code, qui s'avèrent faux lorsqu'on passe au benchmark. Le premier conseil pour optimiser est donc plutôt d'utiliser un profiler pour détecter où le programme passe le plus de temps, puis de n'optimiser qu'en testant à chaque étape (avec un vrai benchmark pas juste une estimation) si on gagne vraiment du temps.
Et bien sûr commencer par optimiser le code est une erreur fréquente du débutant : la première chose à faire c'est se demander si son algorithme est vraiment adapté, si les structures de données choisies sont les bonnes, etc...

Ensuite si vraiment c'est encore trop lent, on peut consulter l'article dont j'ai donné le lien dans mon premier post : il est vraiment bien fait et intéressant.

--
Jedaï

[Jedai]

qu'entends tu par les placeholders ???

Au lieu de faire une requête en concaténant explicitement ses parties, ce qui peut en plus poser des problèmes de "caractères spéciaux" dans les parties dynamiques, il vaut mieux mettre des "?" à la place des parties dynamiques puis faire la requète en passant en paramêtre les parties dynamiques : ainsi DBI se chargera d'éviter les problèmes de caractères, et si on utilise plusieurs fois la même requête avec des paramètres différents, il y a un certain nombre de bases de données pour lesquelles DBI peut optimiser cette opération. Double gain donc, sans perte de lisibilité.

--
Jedaï

[Ickou]

Pour moi optimiser un script, c'est avant tout faire des choix entre RAM ou processeur et cela dépend de la machine où va tourner le script...

un exemple : la commande "sort" utilise beacoup de RAM donc peut faire swapper et planter un serveur.
Donc on peut faire le choix d'utiliser le processeur en parcourant la liste plusieurs fois et permuter 2 à 2 les valeurs jusqu'au moment où l'on a parcouru la liste entière et qu'il n'y pas eu de changements..... cet algorithme est très long à s'exécuter mais peut trier des listes contenant des milliards de valeurs sans planter l'ordi....

Mais bon, c'est pas plus mal quand le script est rapide.

Je vais essayer le module dont parle djibril (File::Sort)....

[Jedai]

Un aspect très important de la question :
Utilisez-vous des très gros ensemble de données ? Dans ce cas, il faut absolument considérer la possibilité d'utiliser le module PDL : ce module permet de stocker des données aussi efficacement que dans un tableau C et donne accès à des routines de manipulation de ces données ultra-rapides, autrement dit, il transforme Perl en langage crédible pour effectuer des très gros calculs et manipulation de données. (ce qu'il est déraisonnable de faire avec les structures de données normale de Perl : le coût en RAM et en indirections par objet devient très vite prohibitif lorsqu'on manipule des dizaines de millions de nombres. Par exemple les tableaux/listes Perl contiennent des **SV autrement dit, des pointeurs vers des pointeurs vers des scalaires, qui sont eux-même des structures de donnée complexe. La flexibilité que cela apporte est très grande et très utile, mais cela ne fait pas bon ménage avec les très gros besoins. PDL corrige ceci)

--
Jedaï

[Invité]

Une page intéressante sur le sujet chez IBM http://www-128.ibm.com/developerwork...l-optperl.html

[mhooreman]

1. Eviter les `` et system(), mais préférer les commandes internes

2. Si on peut éviter $1, $2, $3, ... au sein d'un script, le faire; sinon, les utiliser le plus souvent possible.

3. Coding style:

Keep
It
Simple
Stupid

+ use strict
+ use warning
+ indentation correctes

(ca peut paraitre bizzare, mais au mieux c'est codé, au moins c'est fouillis, et au mieux on voit ce qui peut poser problème)

[Woufeil]

Un bon code passe par un bon algorithme bien sûr mais passe aussi par une bonne utilisation des spécificités du langage que l'on utilise.

Un exemple simple est l'utilisation de boucles foreach à la place de boucle for. Sans avoir fais de benchmark, je pense que pour le traitement élémént par élément d'un tableau (ou même mieux d'un hachage) la boucle foreach est plus performante (sinon elle n'aurait pas été inventée).
Autre exemple, n'utiliser la POO que quand elle est vraiment utile car une utilisation abusive aboutie à une réduction d'éfficacité du code, contrairement à ce qu'il se passe en C++.

Pour le reste, bah ça a déjà été dit hein

[lxmathx]

Je travaille en sécurité et nous développons beaucoup en Perl à mon grand regret, du moins au début!!!

Je me suis rendu compte de la puissance du langage au fur et à mesure de son utilisation.

Dernièrement, nous avons débuter l'utilisation "d'objet" en Perl et nous avons obtenu de la performance et de la maintenance de code hors pair! Nous travaillons notamment constamment avec des objets AD et IIS. Cela nous a permis d'optimiser tous nos scripts et de développer des modules communs.

Je vous conseille donc de ne pas hésiter si vous avez la chance et des travaux plus complexe à faire, utiliser des objets! C'est très simple à programmer et pour quelqu'un qui vient de langage comme Java et .Net, c'est vraiment plaisant de sortir du monde script "pur"!!!

[Woufeil]

Je travaille en sécurité et nous développons beaucoup en Perl à mon grand regret, du moins au début!!!

Je me suis rendu compte de la puissance du langage au fur et à mesure de son utilisation.

Dernièrement, nous avons débuter l'utilisation "d'objet" en Perl et nous avons obtenu de la performance et de la maintenance de code hors pair! Nous travaillons notamment constamment avec des objets AD et IIS. Cela nous a permis d'optimiser tous nos scripts et de développer des modules communs.

Je vous conseille donc de ne pas hésiter si vous avez la chance et des travaux plus complexe à faire, utiliser des objets! C'est très simple à programmer et pour quelqu'un qui vient de langage comme Java et .Net, c'est vraiment plaisant de sortir du monde script "pur"!!!

Ah, enfin quelqu'un qui ne critique pas le modèle objet de Perl, voilà qui fait plaisir !
Je voudrais juste rajouter que dans certains cas très rare, les objets oeuvent se réveler assez lent en Perl, mais qu'en général, ils aident à la clarification, à la maintenabilité, à la possibilité d'extension et à la réutlisabilité du code, sans que cela se ressente niveu performance.

N'hésitez donc pas à les utiliser comme dit lxmathx

[pospos]

l'arme ultime (et trop méconnue) pour les objets en perl : enum::fields
http://search.cpan.org/~dmlloyd/enum-fields/

[mobscene]

Pour optimier mes scripts , je commence déjà avant de coder a poser noir sur blanc ce que doit fait mon progo, ensuite je réfléchie a comment il vas devoir faire (les fonctions a coder etc...), puis seulement je code biensur quand une partie d'un script demande de faire du code redondant , je me réfléchie a comment faire en sorte de ne pas avoir ce problème en faisant tout simplement cela par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
DEBUT
 SI VAR > 0
   SI TOTO > 0
      Traitement
       :-> blablabla
       :-> blablabla
 SINON
      Traitement
         :-> vive develloppez.com :mrgreen:

Tout cela me permet du faire du code pas trop mal

[mobscene]

l'arme ultime (et trop méconnue) pour les objets en perl : enum::fields
http://search.cpan.org/~dmlloyd/enum-fields/

ce truc est génial chui amoureux c'est la fete du slip