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

[mhooreman]

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).

Sans vouloir entrer dans la polémique, j'ai toujours cru (cfr camel book) que for et foreach étaient synonymes.

[Woufeil]

Bah je pense pas non, la syntaxe est totalement différente et on peut pas utiliser un foreach à la place d'un for dans tous les cas (mais un for peut toujours remplacer un foreach il me semble).

Code :

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

1
2
3
4
5
6
7
8
#Boucle pour utiliser chaque élément d'un tableau avec for
for (my $i=0;$i<$#tab;$i++)
{#faire quelque chose avec $tab[$i]
}
#La même avec foreach
foreach my $elem (@tab)
{#faire quelque chose avec $elem
}

Je pense que si elle a été créée, c'est que la seconde boucle doit être plus optimisée que la première...
D'ailleurs la documentation de Sylvain Lhuillier dit ceci :

Cette instruction permet de parcourir une liste. Son implémentation optimisée dans l'interpréteur Perl rend son usage bien plus efficace qu'un parcours qui utiliserait une variable indicielle incrémentée à chaque tour d'une boucle for.

Enfin, c'est mon avis en tout cas

[Mersenne]

Bonsoir.

Je pense comme mhooreman que for et foreach sont rigoureusement synonymes.

Voyez cet 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
34
 
#!/usr/bin/perl -w
 
 
use utf8;
use Tk;
use warnings;
use strict;
 
 
my $mw = MainWindow->new;
 
 
my @tableau = (10, 20, 30);
 
my $somme = 0;
 
 
foreach (my $i = 0; $i <= 2; ++$i) # Ceci montre qu'on peut mettre foreach là où on peut mettre for.
{
  $somme += $tableau[$i];
}
 
$mw->messageBox(-message => $somme,);
 
 
$somme = 0;
 
for my $element (@tableau) # Ceci montre qu'on peut mettre for là où on peut mettre foreach.
{
  $somme += $element;
}
 
$mw->messageBox(-message => $somme,);

La première boucle (foreach), qui utilise un indiçage numérique, mérite les mêmes critiques qu'un for qui utiliserait lui aussi cet indiçage.

La second boucle (for), qui n'utilise pas d'indiçage numérique, mérite les mêmes éloges qu'un foreach qui n'en utiliserait pas non plus.

[Woufeil]

Après relecture du Camel Book, il me sembe que c'est effectivement le cas. Ca m'étonne beaucoup que Sylvain Lhuillier se soit trompé, mais cela semble être le cas...

[Mersenne]

Après relecture du Camel Book, il me sembe que c'est effectivement le cas. Ca m'étonne beaucoup que Sylvain Lhuillier se soit trompé, mais cela semble être le cas...

Je ne sais pas si Sylvain Lhuillier s'est trompé : il n'en a pas à for ou à foreach, il critique l'indiçage numérique, et l'indiçage numérique est aussi critiquable avec foreach qu'avec for, je crois.