Discussion :

[el_slapper]

Le succès des développements disons "embarqués" est pour moi une très bonne nouvelle justement pour que les développeurs reprennent de bonnes habitudes

Le débat n'est pas celui des IDE, ils sont très bien, la génération de code automatique, c'est toujours discutable quand ça génère des usines a gaz (in maintenables qui plus est!). Je parlais plutôt de mauvaises pratiques de programmation, la question n'est pas d'optimiser "a tout prix", simplement d'avoir quelques réflexes de bon sens en développant quand l'écriture d'un code "économe" ne prend pas plus de temps, simplement une question d'habitudes.

Ecrire le close quand j'ouvre un fichier, le lire avec un buffer, aider le gc en déréférençant ses objets, utiliser les algos (tri, recherches ...) standards ... se préoccuper de ses appels système, IO, de la performance de ses requêtes database, ... des exemples, je pourrais en donner des dizaines, je suis assez ahuri que ces "bonnes pratiques" se soient quelque peu perdues.

+1

l'idée n'est pas d'optimiser à fond. L'idée est de ne faire que ce qui est nécéssaire - et de connaitre sa machine. Par exemple, sous Cobol-MVS, le seul élément vraiment couteux, ce sont les accès base. Tout le reste : lecture/écriture fichiers plats, tris, calcul CPU, va très vite. Donc on fait gaffe à limiter au maximum les accès référentiel, et le reste, on fait moins gaffe.

"aider le gc en déréférençant les objets", j'ai appris ça à mes dépends en VBA-Excel. Quand un objet a pour propriété un autre objet, le GC a tendance à oublier des choses, et j'avais un code(qui ne travaillait qu'en mémoire) qui était de plus en plus lent à chaque execution(alors qu'il ne faisait que lire, mémoriser, et traiter). 1 seconde, 2 secondes, 3 secondes, c'était impressionant. Maintenant, quand j'ai besoin d'un objet, je commence par :

Code :

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

1
2
3
4
5
Dim MonObjet as MaClasse

(.../...)

Set MonObjet = nothing

et ceci, avant tout codage au milieu.

[GPPro]

Exemple que je vis en ce moment :

Exemple vécu ces jours-ci :

Code :

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

1
2
3
4
Point  ( x, y )

Point.GetX ()
Point.GetY ()

2 appels de fonctions (donc overhead) pour obtenir les coordonées d'un point....

Aujourd'hui on est en droit d'attendre d'un compilo qu'il soit capable d'"inliner" ça.
Pour ce qui est de la concision du code, c'est un autre problème...

[bretus]

2 appels de fonctions (donc overhead) pour obtenir les coordonées d'un point....

Entre ce genre de chose et devoir copier mes structures pour les rentrer dans l'algorithme, désolé...

Si je fais un algorithme géométrique chiadé brassant des millions de points, je ferai en sorte de pouvoir l'utiliser sans copier les points avant de rendre l'adaptation impossible pour gratter (inutilement) un appel de fonction :

Code :

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

1
2
3
4
5
template < typename Point >
inline double x( const Point & p ){
       return p.x ;
}

Vous ne voulez pas copier chacun des points de votre structure merveilleuse? Pas de problème :

Code :

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

1
2
3
4
5
template <>
inline double x( const VotrePoint & p ){
       return p.GetX() ;
}

L'approche p.x est typique d'une approche d'optimisation locale qui coûtera très cher globalement si elle amène à des copies. (Accessoirement, on l'aura dans l'os avec un point paramétré sur une courbe, mais on aura déjà tordu le coup à ceux qui se plaignent de ne pas avoir un attribut public x à ce stade xD...)


Notons que cette absence de considération globale plus gravement quand on s'attaque aux structures.

Les optimisations locales de mémoire...

A titre d'exemple, disons qu'on se dise : Mon superbe algorithme de graphe n'a pas besoin des arcs entrant pour faire son traitement. Je vais faire ma classe qui n'indexe pas les arcs entrant, ainsi, je pourrai charger plus d'arc en RAM que les autres!

Je remplis le contrat, mon algorithme est parfait, il ne bouffe pas plus que nécessaire.

Mon collègue à besoin des arcs entrant pour son algorithme : Pas grâve, ils se fait une structure dédiée avec les arcs entrant!

Et mon utilisateur qui mon un programme : Il passe son temps à faire des conversions entre les structures.


Il est triste de faire face à des bibliothèques localement très optimisée mais inutilisable globalement. Je tenais donc à signaler ces optimisations comme malhonnêtes et à encourager des optimisations qui satisfont des classes de besoins...


La structure la plus optimisée n'est pas toujours celle qui permet d'exécuter au plus vite un algorithme particulier, ni celle qui consomme le moins de RAM pour un algorithme particulier et encore moins celle qui est incapable de s'adapter pour gagner un inline

C'est souvent un compromis qui permet l'optimisation d'une série d'algorithmes en terme de temps d'exécution et de consommation de mémoire.

Par ailleurs, j'ai suffisamment lu @souviron pour savoir qu'il vous ne compte pas sur ce genre d'optimisation pour de la géométrie (index spatial mieux utilisé, plus adapté, mise en cache de boite englobante, etc. : Quand on a épuisé ces pistes, on a 100 ans)...


Pour en revenir au sujet initiale, il faut parfois se promener des outils qui ont ces mauvaises pratiques d'optimisation car "ils existent" et "ils sont performants". Ce n'est qu'une fois l'application finale en place que vous pourrez montrer qu'ils sont moins performant qu'une approche dédiée non pas à un algorithme, mais à vos données : Bad luck.

[dchaumond]

Entre ce genre de chose et devoir copier mes structures pour les rentrer dans l'algorithme, désolé...

Oui mais par contre au chapitre des "petites" optimisations qui ne coûtent rien, vu trop souvent ça:

Code :

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

1
2
3
4
5
6
7
8
9
Point.getX()

...

Point.getX()
...

...
Point.getX()

Facile a réécrire en:

Code :

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

1
2
3
4
5
6
7
x= Point.getX()

...
x

...
x

J'ai vécu ça il y a quelques années au grand principe proclamé de la POO :-) seul bémol, certaines de ces belles encapsulation sollicitaient la BDD et cela n'a étonné personne qu'un même objet soit réinstancié vingt fois dans la même section de code.

Ce que j'expliquais plus haut c'est qu'il ne s'agit absolument pas "d'optimisation" mais simplement de bon sens.

[arkhamon]

Ce que j'expliquais plus haut c'est qu'il ne s'agit absolument pas "d'optimisation" mais simplement de bon sens.

Je fais ce genre de choses régulièrement.
PAr contre 20 appels

Code :

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

Point.getX()

ne font pas 20 instances de l'objet... C'est juste 20 appels de la méthode. masi dans le principe tu as raison.

[Loceka]

PAr contre 20 appels

Code :

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

Point.getX()

ne font pas 20 instances de l'objet... C'est juste 20 appels de la méthode. masi dans le principe tu as raison.

Il n'a pas dit ça, il a dit que le getX() faisait un appel en base pour récupérer la valeur de x. Du coup ça plombe légérement les perfs.

D'ailleurs un appel de méthode est de toute façon plus coûteux qu'un simple dépilage de variable.

J'ai pris pour habitude de toujours passer par une variable intermédiaire si je dois appeller plus de 2 ou 3 fois le même getter dans un bout de code.

[el_slapper]

Je fais ce genre de choses régulièrement.
PAr contre 20 appels

Code :

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

Point.getX()

ne font pas 20 instances de l'objet... C'est juste 20 appels de la méthode. masi dans le principe tu as raison.

Pour moi, surtout, c'est plus lisible. Quand on a une formule à la con qui ramène un objet, et que l'objet est utilisé plusieurs fois, de manière claire, alors se trimballer à chaque fois la méthode, c'est plus difficille à lire

Code :

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

1
2
3
4
5
DerniereLigne = ActiveWorbook.Worksheets(1).Range("A65536" ).End(xlUp).Row
(.../...)
Call MySub(DerniereLigne)
(.../...)
NouvelleLigne = Myfunction(DerniereLigne)

me parait plus lisible que :

Code :

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

1
2
3
Call MySub(ActiveWorbook.Worksheets(1).Range("A65536" ).End(xlUp).Row)
(.../...)
NouvelleLigne = Myfunction(ActiveWorbook.Worksheets(1).Range("A65536" ).End(xlUp).Row)

[arkhamon]

Pour moi, surtout, c'est plus lisible. Quand on a une formule à la con qui ramène un objet, et que l'objet est utilisé plusieurs fois, de manière claire, alors se trimballer à chaque fois la méthode, c'est plus difficille à lire

Code :

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

1
2
3
4
5
DerniereLigne = ActiveWorbook.Worksheets(1).Range("A65536" ).End(xlUp).Row
(.../...)
Call MySub(DerniereLigne)
(.../...)
NouvelleLigne = Myfunction(DerniereLigne)

me parait plus lisible que :

Code :

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

1
2
3
Call MySub(ActiveWorbook.Worksheets(1).Range("A65536" ).End(xlUp).Row)
(.../...)
NouvelleLigne = Myfunction(ActiveWorbook.Worksheets(1).Range("A65536" ).End(xlUp).Row)

Au delà de la lisibilité, je pense qu'il s'agit de performances en premier dont il faut s'inquiéter...
La première solution est bien plus performante...

[rimram31]

... je pense qu'il s'agit de performances en premier dont il faut s'inquiéter...

Ce qui m'inquiète perso le plus, c'est que ça me donne le sentiment d'un manque de maîtrise du code ou le développeur fait du rase motte d'où le défaut parfois justement des outils de type IDE.

J'ai peut-être appris a l'ancienne, mais un bloc de code, je le pense avant et le prépare, je ne le code pas "au fil de l'eau" (en principe :-) ). J'ai appris ça en C il y a des années prenant le réflexe d'utiliser des variables locales, ça n'a plus trop de sens aujourd'hui en tant que tel, mais ça en prend quand il s'agit d'appels a des données totalement encapsulées (et donc où les traitements internes peuvent être complexes, voir couteux).

Pire même, le fait d'avoir en plein milieu d'un algo, une référence a une structure de données me perturbe car il me fait penser, disons "logiquement", que l'algo est dépendant de la structure de données. Se "débrancher" de la structure en début de traitement est pour moi beaucoup plus "lisible" dans ce sens où ça met en évidence les réelles dépendances.

(zut, j'ai une boulette de profils developpez en double qu'il faudra que je corrige)

[Bousk]

Je ne vois pas de quelle manière vous pouvez émettre des règles absolues à partir de cet "exemple".

PAr contre 20 appels

Code :

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

Point.getX()

ne font pas 20 instances de l'objet... C'est juste 20 appels de la méthode. masi dans le principe tu as raison.

Chez moi, si getX est correctement inline et ne fait que retourner une valeur sans traitement, alors faire 20 appels à getX ne me dérange pas. Mieux, pourquoi devrais-je m'encombrer d'une variable supplémentaire pour stocker la valeur ? Quitte à parler performance, que ce soit temps de calcul ou utilisation mémoire, une variable inutile en moins, je prends.
Si par contre getX fait un traitement interne avant de retourner une valeur, alors je l'apelle une seule fois et stocke la valeur calculée à utiliser les 20 fois à venir.

Bref, du cas par cas.

[souviron34]

Chez moi, si getX est correctement inline

Corrige-moi si je me trompe, mais inliné ou non, il y a bien une copie (au moins de l'adresse), et 2 jmp, plus 1 multiplication et une addtiion.. Ce qui fait 5 opérations dont 1 multiplication par rapport à 1.... (sans compter que le "jmp" peut demander au oader de loader/déloader)

De plus, si la variable est gardée en registre par l'inline, mais si le premier appel est fait à temps T, puis 2500 trucs se passent, appels mémoires, pages loadées et déloadées, etc etc, puis qu'on ré-appelle, on a bien un nouvel appel complet, non ??

'fin franchement, dépendre d'un "inline" n'est pas pour moi une bonne pratique... Le moment où tu veux basculer sur un micro ou embarqué, patatras !!!!

Alors que c'est pas si compliqué que ça, hein ?? Et que ça viole aucune "règle" de "'lOO"...


Tu vois, c'est ça qui me gêne dans ces attitudes... C'est "on "suppose" qu'on a le top du top du top.... De la mémoire à n'en plus que savoir faire, pas de problèmes de performances...."...

On ne se préoccupe aucunement du gasipllage.. Par contre, alors là on entend des discours à n'en plus finir sur "les calculs de complexité"...

C'était l'exemple que je citais plus haut : oui la "meilleure" méthode sur l'algo sur lequel je travaille est en O(N log^x N). Mais elle utilise au minimum 8 N de mémoire supplémentaire par rapport au brute-force... (et en plus elle donne pas le même résultat, même si elle résoud le problème)..

Rusé, mais de la gabegie de mémoire...

[davcha]

Le plus drôle, c'est que tous ces tricks d'optimisation super bas-niveau sont utilisés pour résoudre des problèmes dont il existe une solution polynomiale, mais dont le super développeur aura préféré une solution exponentielle.

[yann2]

Bonjour

Ce que je trouve encore plus drôle c'est que certains pensent qu'un "mauvais" développeur est "mauvais" parce qu'il utilise un IDE.

Toujours les mêmes débats ici.

Si je prends une hache je ne me transforme pas en bûcheron ? Est ce que pour autant la hache est inutile ? Voire mauvaise ?

Une méthode getXxx qui va chercher quelque chose en base ce n'est pas sympa (c'est encore moins sympa quand elle le fait à chaque fois !). C'est un peu pour ça que je n'aime pas beaucoup le choix de faire du lazy loading silencieux (c'est à dire : "hop je vais chercher un truc en base sans te le dire"). getXxxx ça retourne Xxxx, point final. Si il y un chargement à faire je préfère largement un loadXxxx c'est déjà plus parlant et ça exprime un chargement ; dans la tête du mec qui utilise le code ça fait : "Tiiilt ! Cette méthode peut potentiellement prendre du temps, avoir besoin d'accéder à une ressource, etc."

Sinon dans mon métier on ne cherche pas à gagner 0,000001 nanoseconde donc on se permet d'avoir des attributs privés et appeler des méthodes. D'ailleurs, pour avoir des objets immuables, c'est nécessaire (Objets immuables). Mais, nous n'avons pas de contraintes temps réel. Même si davcha a bien fait remarqué que c'est surtout l'algorithme qui prime, peut être qu'on peut arriver, à un moment donné, à ce genre d'optimisations.


Bref, tout ça pour dire que je ne suis pas d'accord pour pointer les outils du doigt. Les véritables responsables sont soit les formations, soit les techniques de recrutement. C'est mon avis en tout cas.

Yann

[bretus]

J'ai vécu ça il y a quelques années au grand principe proclamé de la POO :-) seul bémol, certaines de ces belles encapsulation sollicitaient la BDD et cela n'a étonné personne qu'un même objet soit réinstancié vingt fois dans la même section de code.

Le problème n'est pas dans le p.getX ou p.x dans ce cas. Si un tondu passe son temps à faire des SELECT, son problème est ailleurs... L'interdire de faire des getters ne changera pas la donne, il trouvera bien le moyen de faire un SELECT par ligne.

Ensuite, une fois qu'il aura lu tous ces bons conseils d'optimisation, vous le retrouverez la prochaine fois en train de transformer vos "p.x()" en "p.x" : Il aura gagné 0.01% du temps d'exécution...

Tu vois, c'est ça qui me gêne dans ces attitudes... C'est "on "suppose" qu'on a le top du top du top.... De la mémoire à n'en plus que savoir faire, pas de problèmes de performances...."...

On ne se préoccupe aucunement du gasipllage.. Par contre, alors là on entend des discours à n'en plus finir sur "les calculs de complexité"...

Pour ma part, ce qui me gène le plus souvent, c'est de tomber sur des personnes en train de pondre du code d'optimisation de bas niveau qui améliore de façon négligeable les performances quand il n'envisage même pas une structure plus intelligente pour limiter les parcours de données.

En BDD, vous pouvez en trouvé en train d'optimiser à mort le client pour éviter des copies quand ils se frappent des seqscans en l'absence d'un indexe.

En C++, ils vous dirons que le parcours du graphe est optimisé car les données sont proches en mémoire. Ils auront juste oublié d'indexer les arcs sortant et entrant et se frapperont des parcours inutiles.

Vous imaginez qu'ils seront nombreux à faire des benchs pour se rendre compte qu'ils passent les 3/4 de leurs à scanner tous les éléments d'un tableau avant de suivre le conseil de virer les getters?

Vous comprenez pourquoi on peut juger qu'il faut orienté vers des méthodes pragmatique d'optimisation avant les vieilles recettes des appels de fonctions?

[arkhamon]

Amusant ce dernier échange...
J'ai le souvenir de me torturer le cerveau pour pondre un space Invaders avec 1 KO de RAM (oui oui vous avez bien lu) mémoire vidéo comprise sur un ZX81. Bon je reconnais que c'était pas fort utile mais bon...
Revenons sur la variable locale et sur le x.getx().
L'appel de fonction, c'est empiler les paramètres, sauver ceratins registres, faire un call, dépiler les paramètres, executer un code (qui peut par le biais des héritages s'avérer très lourd), empiler une valeur de retour, faire le return, dépiler la valeur retour...
Opposé à un simple MOV d'une adresse mémoire...

Alors maintenant oui c'est vrai maitenant on a de la RAM à la pelle, du proc Core i7 quadricore à 3GHZ et du réseau à 1Gb...

Ca donne pour autant le droit de développer comme un porc ?

Il y a une sorte de j'menfoutisme généralisé en informatique qui part du principe que comme les ressources sont (quasi) inépuisables, on peut faire n'importe quoi c'est pas grave. En d'autres termes, je fais de la merde, mais c'est pas grave, la machine corrigera d'elle même, ou pire, masquera mon incompétence par ses capacités élevées.

Et quand on a atteint les limites de la machine ? Je vous rappelle comme ça qu'il semblerait que la loi de Moore se prépare à s'infléchir...

L'encapsulation et la POO ont à mon avis caché une chose importante : développer proprement. Et je parle même pas de la qualité du code source. Je parle des algos ! Et ce que je viens de lire n'est pas de nature à me rassurer, quand je vois que certains critiquent cet esprit d'optimisation au sacrosaitn autel de l'inutilité de gagner 0.01 seconde. Sauf que sur sur 1000 boucles, on est à 10 secondes de gagnées, et sur 1000 clients on st à 3 heures de CPU... Après, faut pas s'étonner de voir des datacenter avec des dizaines de milliers de machines qui pompent du courant...

[Bluedeep]

Il y a une sorte de j'menfoutisme généralisé en informatique qui part du principe que comme les ressources sont (quasi) inépuisables, on peut faire n'importe quoi c'est pas grave. En d'autres termes, je fais de la merde, mais c'est pas grave, la machine corrigera d'elle même, ou pire, masquera mon incompétence par ses capacités élevées.

Une sorte de caricature de notre société si je comprends bien ?

[el_slapper]

Surtout, il faut savoir sur quoi on bosse.

J'ai créé il y a un an un algo à la puissance 4. Vous pouvez jeter les tomates pourries, j'ai l'habitude. Il est certainement méga-optimisable. Mais il est aussi déjà hyper-complexe. Il marche, il est (presque) lisible. Et il dure 90 secondes. Pour un traitement mensuel.

Auparavant, le fichier est enrichi par des appels référentiels. Le bloc dure 6 heures.

A votre avis, est-ce que j'ai plongé dans mon algo complexe pour le complexifier encore et gagner une puissance, ou est-ce que j'ai sauvegardé le dernier appel référentiel pour le ressortir si c'est le même que le précédent?

J'ai mis une heure, et ça m'a fait gagner une heure de traitement. Mon algo complexe est toujours à la puissance 4. Et je m'en fous royalement. Il faudra par contre que je regarde si, par un tri astucieux, je peux encore améliorer la bufferisation de l'enrichissement. C'est simple, ça ne nuit pas à la lisibilité de l'ensemble, et il y a réellement des gains à faire. Je le ferais si on m'en donne le budget.

EN BREF : il faut savoir quelle est la limite : la mémoire? Le CPU? Le budget programmeur? Mon exemple fait gagner du CPU et de la lisibilité, au détriment de la RAM(4 octets, c'est terrifiant comme cout). L'ingéniérie, c'est aussi faire des choix judicieux et de l'analyse de la valeur.

[souviron34]

L'encapsulation et la POO ont à mon avis caché une chose importante : développer proprement. Et je parle même pas de la qualité du code source. Je parle des algos ! Et ce que je viens de lire n'est pas de nature à me rassurer, quand je vois que certains critiquent cet esprit d'optimisation au sacrosaitn autel de l'inutilité de gagner 0.01 seconde. Sauf que sur sur 1000 boucles, on est à 10 secondes de gagnées, et sur 1000 clients on st à 3 heures de CPU... Après, faut pas s'étonner de voir des datacenter avec des dizaines de milliers de machines qui pompent du courant...

+1 avec le reste, et +1000 avec ce paragraphe en particulier...

Et, par rapport au sujet, les appels systématiques aux outils externes y participent efffectivement.... de même que l'utilisation d'IDE...

Une sorte de caricature de notre société si je comprends bien ?

Très certainement...

L'ingéniérie, c'est aussi faire des choix judicieux et de l'analyse de la valeur.

Nous sommes d'accord, cependant comme le dit arkhamon cela donne-t-il le droit de programmer comme un porc ??? L'ingéniérie, c'est aussi faire des trucs "smart".. et efficaces...

Même si ta voiture avait un détecteur d'obstacles et de dépassement de lignes, cela te donnerait-il le droit de ne pas regarder la route ??

[davcha]

L'appel de fonction, c'est empiler les paramètres, sauver ceratins registres, faire un call, dépiler les paramètres, executer un code (qui peut par le biais des héritages s'avérer très lourd), empiler une valeur de retour, faire le return, dépiler la valeur retour...
Opposé à un simple MOV d'une adresse mémoire...

En fait, si ton appel de fonction n'est en effet rien d'autre qu'un mov au final, il y a fort à parier que ton compilo aura fait cette optimisation. Même si tu n'as pas explicitement demandé d'inliner ta fonction.

Ou alors, faut penser à mettre l'option -O3.


Pour ce qui est de la POO qui aurait caché "développer proprement, même pas au niveau du code, mais de l'algo", là, j'ai beaucoup de mal, en fait. L'algo, c'est des maths. Y'a pas vraiment de POO à ce niveau là. Donc comment la POO a-t-elle caché ça ?...

POO ou pas, à mon avis, on aura toujours des programmes qui auraient pu être écrits de façon à être plus performants, en temps ou en mémoire.... C'est complètement idiot ce que je dis là : la plupart du temps, les objectifs temps et mémoire sont anti-corrélés.

Enfin, ce que je veux dire précisément, c'est que même sans la POO, vous auriez trouvé le moyen de râler en disant que "tel framework", "telle bibliothèque de fonctions", "tel mot clef d'un langage quelconque", etc... pourrit le code et qu'il est la source du mal.

C'est faux, à mon avis.

[gangsoleil]

Au delà de la lisibilité, je pense qu'il s'agit de performances en premier dont il faut s'inquiéter.

Il faut prendre en compte les performances, mais aussi les attentes ; et en ce sens, l'exemple de el_slapper est criant de verite : il a un traitement mensuel a faire qui suit une tache de 6 heures. Dans ce cas precis, que le traitement prenne 9, 90 ou 900 secondes, l'impact est negligeable (4.17% de temps supplementaire dans le cas d'un traitement de 900 secondes).

Donc s'il existe une solution triviale, qui ne prend qu'une heure a implementer, et qui s'execute dans ces bornes, pourquoi se compliquer la vie a chercher l'optimisation pour quelques minutes ?


Il y a un certain nombre de regles plus ou moins (me)connues sur l'optimisation, dont :
Do not optimize
Pour les experts : Do not optimize yet

Et bien sur la regle des 80/20 : on passe 80% du temps d'un logiciel dans 20% du code. Donc chercher a optimiser le reste des 80% du code, c'est la plupart du temps du temps perdu.
On voit par exemple trop souvent de belles optimisation sur de la lecture de configuration, appelee une seule fois lors du lancement, mais pas dans la boucle principale, appelee plusieurs fois par seconde.