Ico Chamois d"or
Ico Polémiquons
Ico Le saviez-vous ?
Ico Dossier
Ico Club de lecture
Ico Le Petit Geste du Jour
Ico Réseau
Ico Messagerie
Ico Navigateur
Ico Système
Ico Multimedia
Ico Divers

Résultat de votre recherche


1 2 3 4 ... 7
La Programmation Responsable (4) : de spammer ta base de données tu cesseras
Date 28/11/2017
Ico Dossier
Comms Aucun commentaire


"Soleil de printemps

Boîte aux lettres repeinte

Dégoulinades jusqu’à terre"


Hara Sekitei (1889-1951)


Ah mais tout de même. Enfin un article dont nos amis programmeurs comprennent le titre et savent de quoi-t-on va parler, voilà qui ne serait pas du luxe. C'est que tout développeur ne connaît que ça, la base de données. Il l'appelle, la rappelle, lui envoie des petits coucous, prend de ses nouvelles, discute avec elle du temps qu'il fait, et ce toute la journée durant. Eh bien, une fois de plus, c'est malheureux de toujours en arriver là, les souris vertes doivent mettre les pieds dans le plat et mettre le holà à cette idylle apparemment parfaitement innocente. La manipulation sans précaution de notre gentille base de données est LA cause noumero uno (una ?) d'inefficacité des programmes dans le monde, et donc une alliée bien malgré elle du gaspillage informatique à tous les étages, et du réchauffement climatique qui s'ensuit.


Il va donc nous falloir renverser la tête pour arrêter de marcher sur la vapeur, et ce même si cette si cette image vous laisse aussi perplexe que moi. Essayons de comprendre pourquoi la base de données n'est pas le formidable couteau suisse du programmeur que l'on imagine souvent, mais plutôt sa version masse d'armes de vingt kilos à pommeau incrusté que l'on maniera avec la délicatesse d'Hercule, en fin de journée et un peu pressé de finir son onzième travail sur douze.



A la vitesse de l'électron, mais avec un boulet au pied


La base de données est, c'est bien connu, la meilleure manière en programmation de ranger ses petites affaires et de les avoir sous le coude instantanément. La meilleure, vraiment ? Commençons par un petit rappel salutaire directement recopié, sans reversement aux ayants droits, de notre magnifique dossier sur les grandeurs numériques, en se remémorant les ordres de grandeur de latence suivants :


- depuis le cache processeur : 0, négligeable, rien du tout, niente, le processeur travaille directement avec son petit cache qu'il garde auprès de lui

- depuis la mémoire vive (ou RAM pour les intimes) : 10 ns, soit 0,00001ms

- depuis un disque dur SSD : 0,01 à 0,1ms

- depuis un disque dur à plateau : 1 à 10ms

- à travers un appel réseau : de 0,1 à 1ms si on est sur un réseau local très performant, de l'ordre de 30ms si l'on est à travers des connexions distantes


Mais pourquoi donc rappeler tout cela, me demande une souris qui gratte ses mignonnes petites oreilles de consternation ? C'est qu'il nous faut nous poser la question : où est notre base de données là-dedans ? En fait, elle est à cheval sur trois catégories : elle travaille pour partie en mémoire vive (grâce à un cache plus ou moins performant), pour une grosse partie depuis le disque dur, mais il faut lui ajouter une petite latence réseau, car elle est en général déportée sur une autre machine et, quand ça n'est pas le cas, toute la couche des appels réseaux est utilisée quand même pour des appels en local.


Alors, nous voyons tout de suite le problème d'appeler sans arrêt notre base de données : à chaque appel, on paye quelques millisecondes, voire beaucoup plus quand on fait des requêtes maousse costaudes, et des millisecondes qui s'entassent, eh bien ça fait des secondes, puis finalement des heures, voire des jours. Alors que l'on voit tout de suite que si nos données étaient toutes en mémoire, eh bien on irait constamment à la vitesse de la mémoire vive, soit 100 000 fois plus vite, excusez du peu. L'idéal étant même de toujours s'arranger pour travailler dans le cache processeur, là on tombe carrément dans la vitesse intersidérale absolue, sauf que c'est bien difficile à réaliser en pratique si l'on ne programme pas dans un langage qui permet de gérer finement l'allocation mémoire, et désormais très peu de langages modernes l'autorisent, vu que c'est aussi une source d'erreurs fatales et de cataclysmes sans nom. Cela dit, nous ne sommes tout de même pas obligés de nous mettre les mêmes contraintes pour notre petit programme que pour la séquence de lancement d'une fusée en temps réel, donc déjà si on arrête de spammer la base de données à tout va et qu'on sollicite un peu plus la mémoire vive de notre machine on sera bien content.


Bien entendu, il n'y a pas équivalence stricte entre ces méthodes de stockage de données : les données en mémoire vive ou dans un cache processeur sont volatiles, alors que dans votre base de données, elles seront persistantes (enfin si tout va bien). Remarquons d'ailleurs la tendance bien navrante de certains programmeurs à utiliser leur base de données comme fourre-tout pour y mettre des données qui n'ont aucun intérêt à être stockées, comme des résultats de calculs intermédiaires, des caches temporaires, etc, tout ça parce que c'est bien facile de tout ranger dans le gros placard que de travailler un peu à gérer des structures de données en mémoire. Résultat des courses, c'est la double peine : vous perdez en performance à appeler sans cesse votre base de données, et en plus vous consommez du stockage inutilement pour des données qui peuvent être recalculées à la demande.


Il existe aujourd'hui des bases de données non relationnelles fringantes, ou encore des systèmes de cache clé-valeur excessivement plus performants qu'une base de données traditionnelle, comme Redis pour n'en citer qu'un, et qui seront bien utiles dans certains contextes, comme le fait de partager certaines données volatiles entre plusieurs serveurs. Cela dit, même quand ils travaillent exclusivement en mémoire, bravo à eux, ils resteront toujours nettement moins performants que l'utilisation de la mémoire vive au sein même de la zone d'exécution de votre propre code : vous évitez ainsi de payer une petite (ou grosse) latence réseau, ainsi que tout un traitement lié au protocole de transfert aller-retour à la base et son interprétation dans le langage de programmation que vous êtes en train d'utiliser, bref un tas de choses qui ne coûtent pas bien cher si on se sert de sa base de données avec parcimonie, mais qui commencent à chiffrer sévèrement dès qu'on fait tourner plusieurs milliers de fois par seconde notre petit code.



Allô, la base de données ?


Bien bien, on vous a compris, les souris, on jette la base de données à la poubelle et on ne fait plus que du code en mémoire, merci et salut. Attendez ! Ne partez pas si vite, on ne va pas se quitter sur un malentendu pareil : il n'est pas question de mettre toute notre application en mémoire partout et tout le temps, sinon on a remplacé une nuisance par une autre. De toute manière c'est tout simplement impossible, car vous avez sans doute remarqué qu'on est loin de pouvoir mettre autant de mémoire vive sur une machine qu'elle n'a de stockage disponible. Si votre application consomme 100 Go sur disque dur, vous aurez bien du mal à obtenir l'équivalent pour passer l'ensemble en mémoire vive, même à considérer que ça prendrait strictement la même place, ce qui n'est pas vrai (le stockage en mémoire consomme toujours légèrement plus de place que la donnée elle-même).


Bon, donc on ne jette pas notre base de données à la poubelle, au contraire même : c'est tout de même une technologie super robuste pour stocker des données de manière persistante et garantir leur intégrité, beaucoup mieux que s'il fallait faire ça soi-même par des bouts de fichiers, ou tout autre technique tordue qui vous viendrait à l'esprit. Simplement on va s'interdire d'appeler trop souvent notre base de données, pour ne pas payer le coût prohibitif de l'appel à chaque fois qu'on a besoin d'une donnée. Imaginez un peu un code de 100 lignes qui appelle la base de données toutes les 10 lignes pour faire un traitement. Disons qu'on perd 1ms à chaque appel, ce qui est déjà très optimiste, donc notre code s'exécute en 10ms. Si on a réussi à faire tous ces appels en une fois, on ne paye déjà plus que 1ms, on a déjà gagné un facteur 10. Mais si en plus on a anticipé, et préparé dans une autre section de code ces données et qu'elles sont déjà en mémoire, là notre bout de code s'exécute de manière quasi instantanée.


Alors évidemment, ceci supppose d'arrêter de manier à la truelle un concept de programmation particulièrement en vogue, mais qui est une ineptie en terme de performances : l'absence de contexte. Je fais ma petite fonction qui s'occupe de son petit calcul et ne sait rien du reste du monde, mieux encore, je l'appelle au travers d'une API comme ça c'est super étanche, elle ne sait rien de mon application, c'est l'insouciance bienheureuse de l'ignorance béate. Ces principes sont très sains appliqués à une certaine échelle, pour éviter ce qu'il faut bien appeler un sac de noeud géant qui constitue malheureusement la réalité sordide de bien des projets informatiques ayant dérivé dans la nuit, mais ils sont franchement délétères quand on les reporte à une échelle microscopique, puisque l'on va finir par payer un coût exhobitant à chaque micro-étape de notre programme.


Aux Souris Vertes, nous avons un Principe Majeur s'agissant de structurer correctement son application : toute partie du code qui utilise un tant soit peu intensément les données doit pouvoir disposer de la logique complète de la manière dont elles sont structurées, et même la guider : on stocke toujours ses données de la manière la plus adéquate pour les reprendre ensuite, et pas selon un schéma préétabli qui fait beau sur le papier, mais qui est totalement impraticable pour la machine. C'est quand même elle qui travaille à la fin, non mais.


Résumons en quelques savants conseils percutants notre manière de gérer la base de données en Programmeur Responsable :

- mutualiser autant que possible les appels successifs, quitte à organiser le code autrement. Par exemple, je dois récupérer la date de naissance d'un utilisateur à partir de son login à chaque fois qu'il se connecte. Soit je fais un appel à chaque connexion, soit je charge une fois pour toute en mémoire une relation (login,date de naissance), et du coup je ne fais plus jamais d'appel à la base pour cette petite information triviale. Evidemment, si j'ai 30 millions d'utilisateurs, il va falloir que je commence à me poser des questions car cela va vite saturer joyeusement ma mémoire vive. On peut essayer d'optimiser le stockage en mémoire, mais effectivement passé une certaine échelle on ne pourra plus agir aussi simplement. En même temps, dans 99,99999% du temps vous aurez des petites quantités de données à traiter, disons moins de 100 000 d'un coup, et vous pouvez y aller gaiement avec ce genre d'optimisation qui ne coûte pas cher.

- maîtriser la logique globale de l'accès aux données dans l'application, en particulier savoir quelles parties de code écrivent ou lisent dans la base de données pour ne pas faire de traitements redondants ou des appels inutiles, pour des données que vous auriez pu vous repasser d'un bout à l'autre du code.

- stocker les données sous la forme la plus adaptée à la manière dont elles sont ensuite extraites. Le paradigme des bases de données relationnelles, je-mets-tout-à-plat-et-après-je-fais-30-jointures-si-j'ai-besoin, est en ce sens désastreux. En principe, on sait toujours comment une donnée est récupérée (toute seule ou en groupe, filtrée selon un attribut particulier, etc) et il faut en tenir compte dans la manière de structurer son stockage en base. Rappelons également que la création d'index à tout va quand on se rend compte que les performances sont abyssales, généralement lorsque l'on requête sur un ou des attributs que l'on n'avait pas anticipés, n'est pas une méthode viable : chaque nouvel index créé peut dépasser la taille des données brutes stockées, ce qui fait qu'on consomme du stockage à gogo sans vraiment corriger le problème, qui se trouve, comme presque toujours, au sein de la logique que déroule notre code.


Voilà, nous n'allons pas multiplier les conseils aujourd'hui, le principe est simple : on contrôle finement les appels à notre base de données, de manière à en faire le moins souvent possible. Et une fois qu'on a pris nos petites habitudes, on peut les appliquer même quand il n'y a pas forcément un enjeu important de performances, car il n'y a pas de raison de gaspiller des ressources machine, même quand la différence n'est pas perceptible à l'oeil nu. Bien sûr, on cherchera toujours un équilibre entre la complexité du code à écrire et à maintenir, et le gain réel en performance.


Allez, on s'arrête là pour aujourd'hui, vous avez déjà largement de quoi méditer. On se sépare sur un petit haïku providentiel :

"Ciel d'hiver -
La neige répond
A l'appel du rocher"

Midoriro no Mausu (la Souris Verte)

>Voir le billet et ses commentaires...
 

La Programmation Responsable (2) : de ricaner en cours d'algorithmique tu arrêteras
Date 04/11/2017
Ico Dossier
Comms Aucun commentaire


"Devrait-on rire ou pleurer

Quand ma belle-de-jour

Se fane ?"


Matsuo Bashõ (1644-1695)


On entame aujourd'hui notre belle croisière dans les eaux de la programmation estampillée souris verte, et sans se prélasser sous les cocotiers, on franchit tout de suite le Cap Horn en bravant la tempête, et en attaquant de front et par vent de face le sujet le plus austère de tout le dossier, j'ai nommé l'Algorithmique. Rien qu'à lire ce mot, je vous vois plisser des yeux, mais qu'est-ce que c'est que ce truc ? C'est bien simple, sa seule mention fera sortir aussitôt de la salle tout étudiant en informatique qui n'est pas assoupi, ainsi sans doute que des hordes entières de lycéens qui sont désormais sommées de se farcir une version édulcorée de cette matière peu réjouissante.


Car oui, bien qu'on nous rebatte les oreilles à longueur de journal télévisé sur les merveilles réalisées par les incroyables algorithmes qui changent le monde, il ne se trouve pas grand monde en vérité pour défendre cette science des algorithmes qui exerce le même entrain guilleret qu'une marche funèbre sous un crachin hivernal. Les algorithmes changent peut-être le monde (inutile de me mordiller l'orteil, chère souris sous le bureau, nous remettrons la discussion de ce point à un autre article percutant, pour aujourd'hui on tient notre cap), mais c'est avant tout en distillant un ennui profond à notre jeunesse désabusée. Et alors ? L'informatique n'est-elle pas censée être ludique ? Où sont les couleurs qui clignotent, les rires qui fusent, les images qui percutent ?


Eh bien non, c'est malheureux, vraiment, mais l'algorithmique appartient à la face cachée théorique de l'informatique, avec par exemple la logique qui est une autre matière qui fait bien mal au slip, pour le dire poliment, mais qu'on passera sous silence pour ne pas achever de terroriser nos lecteurs. Donc, effectivement, on ne s'amuse pas autant en cours d'algorithmique qu'à programmer Lance Ton Pingouin sur son téléphone mobile, et pourtant c'est un prérequis fondamental à tout programmeur digne de ce nom, c'est-à-dire tout programmeur qui souhaite maîtriser la Programmation ResponsableTM et sauver la planète tous les jours devant son clavier.


Allez, on plonge tout nu dans le grand bain glacé, puisque c'est pour notre bien et celui de l'humanité. Snif.



Avoir le sens du algorithme


Mouais, les souris, on nous enjoint d'aller en cours (un scandale !), mais encore faudrait-il nous dire ce qu'on est censé y apprendre, vu que le prof a l'air de débarquer directement de l'espace et de parler dans un patois martien que même les petits hommes verts (tiens, tiens, nos copains de l'autre bout du système solaire seraient-ils des écologistes convaincus ?) doivent avoir du mal à suivre. On y vient, justement. L'algorithmique est la science des algorithmes. Donc on y apprend des algorithmes. Et voilà ! Bon, ne partez pas, on va essayer d'en dire un peu plus quand même.


Tout d'abord, qu'est-ce qu'un algorithme ? Bigre, la souris verte à lunettes a levé le doigt avant même que je n'aie commencé à formuler ma question. Quelle fayote celle-là, vraiment. Allez, on lui laisse la parole : "un algorithme est une séquence ordonnée d'instructions dans un langage compréhensible par un humain, ou une souris". Pas mal, même si on aura du mal à garantir que TOUS les humains (ou toutes les souris aussi d'ailleurs) seront capables de le lire, puisqu'il faut tout de même maîtriser un minimum le vocabulaire utilisé pour décrire les instructions, qui peut être assez spécialisé.


En tout cas il y a quelques caractéristiques de notre algorithme qu'il faut souligner :

- il doit être sans ambiguité, donc si deux personnes le mettent en oeuvre, le résultat doit être rigoureusement le même.

- les instructions sont bien des notions élémentaires manipulables par un être humain, pas par une machine, donc il y a un certain niveau d'abstraction par rapport à la programmation, pas question de sombre manipulation d'octet ou d'adressage mémoire ici.


A vrai dire, que vous soyez chamois d'or de la programmation acrobatique ou simple citoyen, vous avez déjà eu maille à partir avec pas mal d'algorithmes dans votre vie, et tel monsieur Jourdain qui fait de la prose sans s'en rendre compte, vous mettez en oeuvre des algorithmes quasi quotidiennement, en ignorant simplement de le savoir. Suivre une recette de cuisine, participer à un exercice incendie, même conduire en respectant le code de la route, tout cela peut plus ou moins être associé à la mise en oeuvre d'algorithmes dans des domaines divers. Pour rester dans un domaine un poil plus scientifique, l'addition posée que vous avez apprise à coup de baguette sur les doigts dans votre enfance est un bel exemple d'algorithme mathématique. Si vous appliquez à la lettre les instructions, vous réalisez votre opération sans faillir, que vos nombres aient 2 chiffres ou bien 300.


On voit tout de suite une des raisons de la désaffection pour la matière pointer son nez : l'application d'un algorithme est totalement mécanique, et on ne pourra pas se féliciter de bien d'autre chose que d'être un gentil petit robot si on le met en oeuvre avec brio. C'est d'ailleurs la raison pour laquelle on cherche à déléguer un maximum de ce travail fastidieux à nos amis les ordinateurs. Bien que la répétition de certaines tâches ait une vertu pédagogique indéniable, et soit partie intégrante de l'apprentissage, il est clair que si l'on reste strictement cantonné à l'exécution d'algorithmes, on va vite sombrer dans une déprime et une apathie généralisées. Non, l'intérêt de l'algorithmique est de concevoir des algorithmes, ce qui est une autre paire de manches et nous fait tout de suite basculer du côté de l'intuition et de la créativité les plus débridées.


Et à vrai dire, même si tu te cures le nez en affichant un air de profond ennui devant nos propos, cher lecteur-programmeur, de l'algorithmique tu en fais, en fis et en feras que tu le veuilles ou non. Car qu'est-ce que c'est finalement que d'écrire un programme informatique, sinon enchaîner une série d'algorithmes qui résolvent chacun à leur manière un petit problème isolé ? Je dois isoler une valeur au milieu d'un gros tas de données ? Je dois traiter une information en provenance d'un utilisateur ? Je dois calculer comment afficher correctement un texte à l'écran ? Que des algorithmes, tout cela. Les seules questions qui se posent sont : est-ce que j'écris mes propres algorithmes, ou est-ce que j'utilise ceux des autres ? Est-ce que je maîtrise leur impact en terme de temps de calcul et de ressources machine utilisées ?



Ne soyons pas trop décomplexés


Avec toutes ces belles considérations, on n'a pas encore vraiment dit ce que l'on apprenait concrètement dans notre cours de gymnastique algorythmique  (sans les collants ridicules, vous voyez qu'il y a du bon dans cette matière tout de même). En général, on étudie des classes d'algorithmes existants de plus en plus complexes, et si tout va bien on apprend comment concevoir les nôtres. On commence par exemple par trier des tableaux dans tous les sens (une grande joie du programmeur débutant, l'équivalent du rite initiatique dans les sociétés traditionnelles), et quand on devient Jedi on peut étudier les algorithmes super monstrueux utilisés par GoogleBook pour coloniser l'internet mondialisé.


Mais surtout, surtout, surtout, on apprend à évaluer les performances d'un algorithme, et c'est bien ce à quoi nous voulions en venir, la compétence clé du Programmeur Responsable qui a son petit badge couleur éméraude. Ce que nous enseigne l'agorithmique, c'est que toute méthode doit être évaluée non par le temps qu'elle prend (qui dépend de conditions locales d'exécution qui peuvent varier), le nombre de litres de pétrole qu'elle consomme ou son signe zodiacal, mais par sa complexité, qui est un ordre de grandeur du nombre d'instructions réalisées en fonction de la taille des entrées de ladite méthode. Et oui, les souris, je sais bien que c'est formulé de façon aussi claire que le fond du ruisseau saturé de boues d'épandage qui court à côté de notre jardin. On va tâcher de prendre un exemple pour éviter de se fouler le néo-cortex.


Attention, cependant, rien à voir avec la soi-disant complexité du monde réel qu'on invoque à toutes les sauces pour nous demander poliment de passer notre chemin et nous signifier de laisser penser les éditorialistes parisiens à notre place, ici il s'agit d'une théorie tout ce qu'il y a de plus sérieux et et scientifique. La complexité ne désigne pas les profondeurs insondables d'une pensée qui nous échappe, pauvres mortels débiles que nous sommes, mais la complexité en nombre d'étapes de calculer un résultat pour une machine qui ne dispose que d'opérations élémentaires pour le mener à bien.


Avant d'aller plus loin, je sens qu'il est urgent d'opérer une petite pause contemplative salutaire, méditons donc un instant sur un petit haïku : 

"Si difficile

De dire ce que voit

Cette souris tournée vers moi"


Midoriro no Mausu (la Souris Verte)


Notre vraiment super exemple


Ouf. Puisque nous voici à nouveau frais, dispos, et prêts à en découdre avec les concepts les plus tarabiscotés, revenons à nos moutons virtuels et à notre fameuse complexité, et prenons un exemple issu de la Vraie Vie, comme on dit dans les salons. Donnons nous par exemple la tâche bien utile de dénombrer les feuilles d'un arbre. Pours nos lecteurs qui passent trop de temps devant un écran à coder et ne savent pas ce qu'est un arbre, nous les enjoignons à sortir prendre un peu l'air jusqu'à apercevoir un grand truc marron en bas, et vert au dessus qui semble pousser dans le sol, ou à tout le moins à se renseigner sur internet.


Bon, comptons donc. Ca paraît bête, comme cela, mais déjà trouver une méthode qui permette de le faire sans se tromper n'est pas si aisé, vu que vous avez pu remarquer qu'un arbre n'a pas forcément une structure bien régulière, qu'il y a des feuilles dans tous les sens, et en plus s'il y a du vent au secours. Si l'on suppose que l'on a quand même accès à toutes les feuilles, quitte à se munir d'une échelle bien costaude, il va falloir se débrouiller pour ne pas perdre le fil et ne pas compter les mêmes feuilles plusieurs fois.


Une bonne idée pour ce faire nous est donnée par le professeur Souriso lui-même, qui adore ce genre d'expérience : on compte une feuille, puis on fait une petite marque (discrète et qui partira à l'eau de pluie, hein, on n'est pas des sauvages) pour ne pas la compter à nouveau. On continue à énumérer les feuilles de l'arbre jusqu'à ce que toutes les feuilles soient marquées, et zou, on a notre total.


C'est formidable, mais il ne vous aura pas échappé que ceci risque de prendre un certain temps, voire un temps certain, et de vous faire mourir d'épuisement avant d'arriver même à la moitié du quart du dixième de votre tâche. Peut-on optimiser un peu notre algorithme, avant d'y passer notre vie ? Cest là que le Programmeur Lambda, celui qui n'a pas suivi de cours d'algorithmique ou y a trop roupillé pour en avoir retiré quelque chose d'utile, va se tourner vers la solution standard de l'informatique en panique : on offre une paire de lunettes à la personne qui fait le décompte, ou bien on lui donne une échelle plus longue, ou même une paire de jumelles si on ne compte pas à la dépense. Bref, on augmente le matériel. Pour un vrai programme informatique on mettra plus de mémoire, un plus gros disque, du SSD, etc. Super, mais vous voyez qu'au lieu d'y passer 107 ans, notre fidèle collaborateur en passera 105 ou 106, bref c'est bien gentil de votre part mais ça ne résout strictement rien.


Qu'à cela ne tienne, on va sortir les grands moyens et paralléliser les calculs, on va mettre non pas une, mais deux personnes qui comptent. Et bim ! C'est aussi une très belle promesse, mais il faut compter que les deux personnes vont se marcher un peu sur les pieds, donc on n'ira pas strictement deux fois plus vite. Mais même comme ça, on mettra 50 ans environ, c'est mieux mais pas franchement jouable quand vos crédits de recherches sont alloués sur 10 mois. Et même en mettant 10 personnes en même temps, bof bof, vous restez toujours avec le même ordre de grandeur, donc si c'était franchement impossible ça deviendra juste-un-peu-moins-impossible mais toujours pas raisonnablement réalisable. Donc ici encore, la fameuse méthode de la parallélisation, si souvent dégainée pour se sortir d'une ornière informatique, outre qu'elle demande un doigté particulier dans la manière de programmer sans se prendre des problèmes de processus concurrents à tous les étages, ne fera jamais gagner significativement en performance.


Deux solutions s'offrent alors à nous : soit on renonce à notre projet, en le repoussant à une époque où la technologie viendra nous aider à le résoudre en un temps raisonnable (avec un ordinateur quantique, pourquoi pas ? On peut toujours rêver), soit on sort une feuille blanche, sa plus belle plume et on change d'algorithme pour réduire sa complexité.


Ici, une suggestion tout à fait passionnante d'une souris débrouillarde nous permet de nous sortir d'affaire : on simplifie le problème, en fait on ne veut pas vraiment le nombre exact de feuilles dans notre arbre, une bonne estimation nous suffira. Nous allons donc estimer le nombre de feuilles sur une branche, et simplement compter le nombre de branches au lieu du nombre de feuilles. Et il y en a beaucoup beaucoup moins, c'est l'affaire d'une heure tout au plus. Et voilà comment un travail qui aurait pu nous prendre jusqu'à l'extinction du soleil est terminé en une petite après-midi de travail, sieste incluse.


Dans notre petit exemple, nous sommes passé d'une complexité qui était proportionnelle au nombre de feuilles dans l'arbre, à une complexité proportionnelle au nombre de branches dans l'arbre. Alors ici c'était facile, mais il n'est pas toujours facile de calculer la complexité d'un algorithme, et encore moins de la faire baisser ; surtout quand ledit algorithme avance masqué dans plusieurs milliers de lignes de code qui semblent parler d'autre chose que de ce que vous raconte le prof martien.


Mais une valeur sûre pour repérer de la complexité sauvage et déchaînée est de repérer de multiples structures de boucles imbriquées dans un programme. Pour chaque niveau de boucle, hop, un ordre de grandeur supplémentaire. Et se souvenir aussi que le meilleur endroit pour améliorer les performances est TOUJOURS au milieu du code et de la logique qu'il déroule, et non dans les solutions de facilité de toujours plus de matériel, ou encore de programmes tiers censés booster les performances, comme des systèmes de cache tout-terrain qui ne savent pas sur quoi ils travaillent, et n'amélioreront donc jamais la complexité intrinsèque d'une méthode.



Savoir s'abstenir de ne pas faire


S'il y a une chose que nous enseigne l'algorithmique et qui doit nous marquer à vie, c'est que ce n'est pas parce que l'on sait écrire un programme qui résout une certaine tâche que l'on est capable de le mettre en oeuvre. Je peux écrire un programme qui sait calculer la factorielle d'un nombre à 130 chiffres, qui fera les mêmes trois lignes que pour la factorielle de 5, mais il n'a aucune chance d'aller jusqu'au bout, vu qu'il lui faudra réaliser plus d'opérations qu'il n'y a d'atomes dans l'univers.


Aussi, si on me demande d'écrire un tel programme, je me dois de refuser car ce serait un gaspillage de ressources éhonté pour un résultat qui n'a aucune chance d'aboutir. Et toi aussi, ami programmeur, refuse de mettre en oeuvre des méthodes à la complexité trop élevée : soit tu trouves une meilleure façon de procéder, soit on dit au client, tant pis, il n'a qu'à se trouver des besoins plus modestes auxquels l'informatique saura répondre sans y sacrifier l'énergie d'une supernova.


Précisons tout de même que toutes ces considérations ne s'appliquent que lorsque l'on traite un volume conséquent de données ; en fonction du type de traitement que l'on cherche à faire, on commencera à se poser de sérieuses questions de complexité au-delà de 1000 à 10000 entrées à gérer d'un coup. En deçà, on peut bien se permettre de privilégier une programmation simple, naturelle et sans nécessité de stockage massif de boîtes d'aspirine sous le bureau.


Et dans le cas où il nous faut optimiser les performances d'une application, on procèdera toujours dans l'ordre d'efficacité croissant, en appuyant d'abord là où ça peut faire le plus de différence :

1 - on étudie complexité générale du ou des algorithmes sous-jacents, et on essaie d'améliorer cela. Plus facile à dire qu'à faire, n'est-ce pas.

2 - on applique les formidables conseils qui vont suivre dans ce dossier, et on optimise donc en particulier les appels aux bases de données, aux disques, etc.

3 - on utilise un système de cache ou des outils d'optimisation de code écrits par d'autres. Si on est en rendus là, c'est que soit on est désespéré, soit on a déjà atteint un niveau d'optimisation tellement énorme qu'on ne peut plus rien faire simplement au niveau du code.

4 - on rajoute des ressources matérielles, et, si on le peut, on parallélise les étapes qui prennent le plus de temps. Ca c'est la solution qui apporte le moins de gain pour le plus de ressources consommées, autant dire qu'on ne la dégainera qu'à bon escient.



Une lueur d'espoir au fond du tunnel


Bon, disons le tout net, il est bien difficile de comprendre quel algorithme vous mettez en oeuvre quand vous programmez au quotidien, même si vous faites à votre insu des parcours d'arbres ou de graphes, des tris de tableaux, etc. Autrement dit, à moins que vous n'ayez une application très spécialisée qui fait du calcul intensif De Maboul, par exemple une méthode d'apprentissage sur un grand nombre de données, vous aurez peu de chances d'arriver à utiliser directement les notions algorithmiques chèrement  apprises. Il n'en reste pas moins qu'elles sont essentielles pour donner des points de repère, et surtout pour vous faire sentir à quel point la méthode de programmer tout ce qui vous vient à l'esprit sans jamais analyser le nombre d'opérations en jeu est délétère, et à l'origine d'une part non négligeable de ces superbes applications Programmées Avec Les Pieds (TM) qui font tant ramer nos belles puces de silicium.

Mais, pour être tout à fait honnête, vous vous en sortirez très bien sans un doctorat en algorithmique si vous mettez en oeuvre les petites astuces et mises en garde qui vont suivre dans cet épatant dossier. Alors surtout ne ratez pas la suite !

D'ici là, nous avons tous gagné le droit à une bonne promenade automnale sous les feuilles d'arbre qui tombent (non non, vous n'êtes pas obligé de les compter). Youpi !









>Voir le billet et ses commentaires...
 

Le Petit Geste Du Jour : je nettoie ma boîte de messagerie
Date 24/10/2017
Ico Le Petit Geste du Jour
Comms Aucun commentaire


"Nettoyage de fin d’année

Dieux et bouddhas

Dans l’herbe"


Masaoka Shiki (1866-1909)


Aujourd'hui un petit geste rapide comme l'éclair, furtif comme la panthère, vif comme le serpent. Enfin en ce qui nous concerne, car pour une fois ça n'est pas nous qui allons travailler à décrire, argumenter, métaphoriser et discoursiser (fort heureusement, car notre langue française part en lambeau à vue d'oeil), mais vous qui allez bosser, non mais.


Le principe est simplissime : nous allons tous ranger notre boîte de messagerie. Youpi ! Allez, on sort tous la serpillère, le balai et le seau, et on s'y met dans un grand geste de ménage de printemps au beau milieu de l'automne. Cependant, le Geste est simple mais la pente est raide, comme dirait un ex-premier ministre que l'on préfèrera oublier. Surtout pour ceux qui, comme la majorité sans doute de nos concitoyens, auront laissé s'accumuler des années de courrier électronique sans jamais rien classer ni jeter.


Allez, ne renâclons pas, plus vite on aura commencé plus tôt on aura terminé. Pour ceux qui hésitent encore, nous les invitons à relire les articles époustouflants sur les pièces jointes dans les mails, tous les gestes précédents sur la messagerie, les données dans le cloud, et tous les autres aussi, si si. Pour n'en garder que l'essentiel, sachez que les serveurs de messagerie travaillent pour vous à garder vos messages bien au chaud comme s'ils étaient tous la version originale du texte le plus sacré de la création, et avec les moyens et la dépense d'énergie associés.


Dans ces conditions, on montrerait beaucoup d'ingratitude à stocker avec autant de frais nos spams pourris aussi bien que notre courrier le plus important. Et ce n'est pas parce que certains fournisseurs de messagerie proposent des espaces d'une taille ridiculement grande qu'il faut se forcer à coloniser leurs baies de stockage. Par exemple, votre serviteur, qui conserve pourtant à peu près l'intégralité de ses conversations électroniques depuis sa naissance, arrive à les faire tenir sans effort dans moins de 200Mo. On peut sûrement faire encore bien mieux, me font remarquer quelques souris vertes éparpillées autour du bureau, elles qui vivent sans avoir de boîte de messagerie au fond de leur petit pré (mais comment font-elles ?).


Quelques pistes pour vous aider dans votre grand nettoyage :

- la cible principale est l'ensemble des pièces jointes. On peut garder le message tout en supprimant les fichiers associés, donc on rapatrie bien vite les pièces jointes que l'on veut garder sur notre petit ordinateur personnel, et on benne tout le reste. Hop, on vient de faire dégonfler la taille de notre boîte de messagerie de 90% d'un coup.

- supprimer évidemment les messages inutiles, les pubs, les vieux messages dont on n'a plus besoin. Généralement les messages les plus courts, comme 'OK pour demain soir', ne servent à rien sur le long terme, ou alors vous avez une drôle de façon de revisiter votre correspondance.

- si vous êtes un adepte de la réponse dans la réponse de la réponse, vous pouvez supprimer tous les messages de la discussion pour ne garder que le dernier de la liste.

- classer ses messages est une bonne idée pour éviter que le flux de nouveaux arrivants ne vienne rapidement refaire gonfler la baudruche. On garde les messages un temps dans une zone de purgatoire, avant de décider de leur sort ultime : on les archive, on les jette ? On supprime d'abord les images et les pièces jointes ?


Ah, et n'oubliez bien évidemment pas de forcer le vidage de la corbeille de votre boîte de messagerie, sans quoi tout ce que vous avez supprimé reste gentiment présent sur les serveurs, mais à un autre endroit moins en vue.


Eh bien voilà, c'est tout pour aujourd'hui. Je note votre circonspection, mais si, c'est possible, aux souris vertes on sait très bien faire court, si on ne se l'impose pas c'est qu'en général on n'en a pas spécialement envie. Nous aurons bien sûr à revenir sur des méthodes de nettoyage de messagerie, car il y a encore des traces de saleté qu'il est impossible d'enlever sans des outils spécialisés, mais pour un premier geste vous pouvez déjà être fier de vous ! Et en plus, malgré tout ce nettoyage, on n'a même pas la peau des mains abîmée, merci les souris vertes quand même. Allez, on se quitte avec une petite pensée pour tous ces animaux sauvages que l'on vient de contribuer à sauver :


"Nettoyage trop féroce

Les rayures du zèbre

Finiront par disparaître"


Midoriro no Mausu (la Souris Verte)






>Voir le billet et ses commentaires...
 

1 2 3 4 ... 7

Infos blog

Des Souris Vertes

Derniers billets

Polémiquons   06/03/2018
A bas le 'c'est pratique'
Le Petit Geste du Jour   04/02/2018
Le Petit Geste Du Jour : je me dirige sans GPS
Club de lecture   21/01/2018
Les souris vertes ont lu pour vous : l'économie symbiotique, d'Isabelle Delannoy
Le Petit Geste du Jour   05/01/2018
Les 5 gestes totalement vraiment incontournables de l'écologie numérique
Le Petit Geste du Jour   22/12/2017
Le Petit Geste de Noël : je ne renouvelle pas ma panoplie numérique
Dossier   16/12/2017
La Programmation Responsable (6) : des sites webs écologiques tu concevras
Dossier   07/12/2017
La Programmation Responsable (5) : les structures de données tu maîtriseras
Dossier   28/11/2017
La Programmation Responsable (4) : de spammer ta base de données tu cesseras
Dossier   18/11/2017
La Programmation Responsable (3) : de déléguer la programmation tu éviteras
Dossier   04/11/2017
La Programmation Responsable (2) : de ricaner en cours d'algorithmique tu arrêteras
Le Petit Geste du Jour   24/10/2017
Le Petit Geste Du Jour : je nettoie ma boîte de messagerie
Dossier   16/10/2017
La Programmation Responsable (1) : Ce dossier tu liras
Réseau   05/10/2017
Mes données dans le cloud : écologique ou pas ?
Dossier   26/09/2017
Au secours, mon ordi est lent ! (8) : J'apprends à reconnaître et changer le matériel
Le Petit Geste du Jour   10/09/2017
Le Petit Geste De La Rentrée : j'arrête le streaming
Divers   25/05/2017
Les souris vertes s'invitent à la radio
Le Petit Geste du Jour   20/05/2017
Le Petit Geste Du Jour : je change les réglages de mon appareil photo
Dossier   11/05/2017
Au secours, mon ordi est lent ! (7) : Je réinstalle mon système tout seul comme un grand
Le Petit Geste du Jour   06/05/2017
Le Petit Geste Du Jour : j'écris un haïku pour me détendre
Divers   14/04/2017
Cultiver l'attente...
Club de lecture   25/03/2017
Les souris vertes ont lu pour vous : la convivialité d'Ivan Illich
Le Petit Geste du Jour   09/03/2017
Le Petit Geste Du Jour : j'enlève la signature automatique des messages
Polémiquons   27/02/2017
L'inquiétant mariage de la science et du numérique
Dossier   17/02/2017
Au secours, mon ordi est lent ! (6) : J'adapte mon système à mes besoins
Club de lecture   12/02/2017
Les souris vertes ont lu pour vous : une question de taille, d'Olivier Rey
Le saviez-vous ?   21/01/2017
Le saviez vous ? La voiture est un ordinateur sur roues
Dossier   10/01/2017
Au secours, mon ordi est lent ! (5) : J'apprends à ne pas perdre mes données
Dossier   30/12/2016
Au secours, mon ordi est lent ! (4) : Je nettoie Windows à grands jets
Polémiquons   23/12/2016
Le Petit Geste de l'Année : je ne commande rien d'électronique au père noël
Le Petit Geste du Jour   11/12/2016
Le Petit Geste Du Jour : j'utilise un bloqueur de publicités
Dossier   27/11/2016
Au secours, mon ordi est lent ! (3) : J'apprends à ne pas polluer mon ordinateur
Dossier   14/11/2016
Au secours, mon ordi est lent ! (2) : Je dégage l'antivirus à coup de pied
Dossier   05/11/2016
Au secours, mon ordi est lent ! (1) : les souris vertes à la rescousse
Le Petit Geste du Jour   23/10/2016
Le Petit Geste Du Jour : j'utilise le mode avion même à pied
Système   16/10/2016
L'ordinateur portable est-il plus écologique ?
Le Petit Geste du Jour   02/10/2016
Le Petit Geste Du Jour : je gère la durée de vie de ma batterie
Club de lecture   17/09/2016
Les souris vertes ont lu pour vous : l'âge des low tech, de Philippe Bihouix
Système   21/08/2016
J'apprends à gérer mes mots de passe
Le Petit Geste du Jour   08/08/2016
Le Petit Geste Du Jour : j'arrête d'inclure les messages quand je réponds
Polémiquons   30/07/2016
Ecole et numérique font-ils bon ménage ?
Le Petit Geste du Jour   19/07/2016
Le Petit Geste du Jour : j'arrête d'écrire mes mails en HTML
Chamois d"or   10/07/2016
Le saviez vous ? Il est possible d'être informaticien sous Windows sans se pendre
Messagerie   04/07/2016
L'incarnation du mal : la pièce jointe dans les mails
Le Petit Geste du Jour   26/06/2016
Le Petit Geste Du Jour : Je réduis la luminosité de mon écran
Divers   18/06/2016
Stop à l'imprimante jetable
Dossier   12/06/2016
Grandeurs du monde numérique (6) : Réseaux en folie
Le Petit Geste du Jour   05/06/2016
Le Petit Geste du Jour : j'éteins ma box quand je ne m'en sers pas
Le saviez-vous ?   31/05/2016
Le saviez-vous : Google n'est pas le seul moteur de recherche ?
Dossier   25/05/2016
Grandeurs du monde numérique (5) : Dans la jungle des écrans
Le Petit Geste du Jour   20/05/2016
Le Petit Geste du Jour : je mets mes sites favoris... en favoris
Le Petit Geste du Jour   15/05/2016
Le Petit Geste du Jour : je change la page de démarrage de mon navigateur
Dossier   14/05/2016
Grandeurs du monde numérique (4) : Les spectaculaires performances des jeux vidéos
Le saviez-vous ?   12/05/2016
Le saviez-vous : à quoi sert l'économiseur d'écran ?
Dossier   08/05/2016
Grandeurs du monde numérique (3) : Monsieur Herz mesure la solitude du processeur
Dossier   06/05/2016
Grandeurs du monde numérique (2) : Octets et compagnie, les rois du stockage
Dossier   05/05/2016
Grandeurs du monde numérique (1) : c'est gros, c'est petit ?
Divers   04/05/2016
Les souris partent à l'aventure


MP  Mighty Productions
> Blogs
> Des Souris Vertes
 
RSS       Mentions légales       Comms  Haut de la page