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 ... 8
La Programmation Responsable (5) : les structures de données tu maîtriseras
Date 07/12/2017
Ico Dossier
Comms Aucun commentaire


"J’ai manqué mon coup
La tête du clou
Est toute tordue"

Nakatsuka Ippekiro (1887-1946)


Hum, bon d'accord, on n'arrête pas de recycler le même dessin sur notre dossier, et alors ? Il faut dire que les titres de nos palpitants articles ne se prêtent pas facilement à une illustration imagée, surtout pour qui dessine avec le talent artistique d'un enfant de 3 ans ayant enfilé une bonne paire de moufles.


Bref, passons ces trivialités car on ouvre aujourd'hui un article excessivement important voire, nous n'avons pas peur de le dire, au moins aussi vital, indispensable et crucial que tous les autres mais même presque plus. Et, pour couronner le tout, il constitue un prolongement renversant à la fois de notre article sur l'algorithmique, non n'ayez pas peur, et de notre dernier article sur la base de données. Rappelez-vous, nous y avions énoncé, en effet, qu'il s'agissait autant que faire se peut de travailler en mémoire, et non à grand coup d'appels débridés à une base de données sympathique mais pas très véloce.


Et justement, aujourd'hui, nous regardons comment stocker efficacement des données en mémoire. Car la mémoire, certes, c'est rapide, mais il y a bien des manières de rendre un programme qui s'exécute entièrement dans cette belle zone nimbée aussi alerte qu'un hippopotame au sortir du déjeuner. Et, une fois de plus, c'est l'algorithmique qui va nous aider à faire la part des choses et à devenir le Programmeur Responsable de nos rêves.


Allez, n'introductions pas davantage car le fer est chaud et nous aussi, autant le battre sans tarder. En voiture ! Je précise que la voiture est à pédale, on ne va pas commencer à émettre des particules fines dans ce bel article aux éclats verdoyants d'automne, quand même. Aïe ! Ca y est, je me fais mordiller la cheville par les souris qui souhaitent qu'on en vienne au fait. On y va, on y va !



Et le menteur, mon cher Ouètsonne


Première révélation qui ne bouleversera pas ceux qui ont lu notre dernier article, nos données doivent être bien organisées pour s'adapter au contexte dans lequel on souhaite ensuite les récupérer. Ce n'est pas parce qu'on va travailler en mémoire que tout ce qu'on peut imaginer est efficace. A vrai dire, aucune structure de données n'est parfaite à tout point de vue, ça serait trop facile, c'est pourquoi il nous faut convoquer un peu nos connaissances en algorithmique et distinguer les opérations élémentaires suivantes :

- je souhaite accéder à une donnée précise dans mon gros paquet

- je souhaite ajouter une donnée à mon gros paquet

- je souhaite retirer une donnée à mon gros paquet

- je souhaite savoir si une valeur donnée appartient à mon gros paquet

- je souhaite énumérer toutes les données de mon gros paquet


Eh bien, c'est à peine pensable, mais il se trouve qu'AUCUNE, non, pas même une seule nulle part dans la galaxie, structure de données n'est parfaitement efficace pour toutes ces opérations. C'est bien la raison du pourquoi du fondement de cet article, en vérité, car il va nous falloir systématiquement faire des choix qui vont favoriser certaines opérations au détriment d'autres. C'est pourquoi tout Programmeur ResponsableTM se doit de connaître sur le bout des doigts une panoplie de structures de données, avec leurs avantages et leurs inconvénients, et d'être capable d'analyser son besoin pour choisir la plus adaptée au moment d'écrire ses milliers de lignes de code.


Le drame pour notre planète, mais qui en voit d'autres de toute manière, est que le choix systématique d'une structure de données pas du tout adaptée produit une pollution toute silencieuse : la machine ne crie pas, ne fume pas, le programme s'exécutera très bien, souvent même raisonnablement vite vu la puissance des processeurs, même ceux qui équipent les barrières de péage, donc personne ne s'aperçoit de ce gâchis constant d'instructions et de cycles machines, à part à la fin des fins l'ours polaire qui doit se déplacer de plusieurs dizaines de kilomètres supplémentaires chaque année pour trouver de la banquise.


Mais nous comptons bien que nos lecteurs aguerris et amateurs de gentilles souris vertes ne s'en laisseront pas conter et feront bien vite tous les efforts nécessaires, quand bien même ils ne recevraient pas de récompense du chef de l'Etat et d'acclamations de la foule en délire pour leur petite contribution stoïque à l'écologie numérique.


Or donc, comme nous le disions, aucune structure de données ne sera efficace pour toutes nos petites opérations élémentaires, et leur degré d'inefficacité se mesure grâce à la complexité propre à chacune de ces opérations, et là vous comprenez que vous avez bien fait de vous farcir notre bel article sur l'algorithmique sans vous assoupir.


Prenons par exemple le fait de trouver une donnée dans notre gros paquet de N données. Supposons que l'on a vraiment rangé tout ça en désordre complet, il nous faudra de l'ordre de N opérations (en général un peu moins, disons N/2 en moyenne, mais l'ordre de grandeur reste le même) pour aller retrouver notre petit copain, en gros on va les énumérer jusqu'à trouver la bonne. Si on a fait un petit effort, par exemple trié à l'avance nos données, on peut s'en sortir avec de l'ordre de log(N) opérations, ce qui est déjà nettement mieux, n'est-ce pas. Rappelons à toutes fins utiles, et sans frimer excessivement nos cours de maths de terminale, que log(10000)=4log(10), par exemple, soit au lieu de 10 000 essais, on en fait une dizaine environ. C'est mieux, non ? Mais toujours plus fort de café, si on a choisi une structure vraiment adaptée, on peut extraire notre donnée en une seule opération. Une seule ! Autrement dit ça vaut quand même bien le coup de choisir, non ?


Alors il se trouve que la plupart des programmeurs ne connaissent que le tableau, qui est une structure bien sympathique, mais qui offre précisément la complexité la moins bonne quand il s'agit d'aller chercher une valeur précise, même si elle a plein de qualités par ailleurs concernant les autres opérations. Bref, les tableaux sont certainement surutilisés (une souris me demande si ça existe, je suis sûr que l'Académie Française se hâtera de nous corriger, voire de l'inclure lors de sa prochaine session , si ça n'est pas le cas), et il serait bien temps de diversifier un peu notre palette en la matière.


Une petite remarque supplémentaire avant de décrire un peu le choix pléthorique au supermarché des structures de données : il faut savoir que toute structure de données n'est concrètement implémentée, à la fin des fins, qu'avec une combinaison de deux structures élémentaires, à savoir les tableaux et les listes chaînées. Couplée à quelques variables bien choisies, et parfois à des fonctions algorithmiques redoutables (comme les fonctions de hachage, par exemple), ces objets sympathiques nous permettent de construire des structures de données nettement plus complexes et adaptées à des situations très diverses. Cela dit, à moins d'utiliser un langage qui n'offre aucune structure de données un tant soit peu élaborée, et il y en a, ou d'avoir un besoin très spécifique en la matière, on aura rarement à implémenter soi-même ses propres structures de données complexes en partant de petits tableaux ou de listes chaînées.


Dernier point, enfin, la complexité en nombre d'opérations n'est pas nécessairement le seul critère qui entre en jeu quand il s'agit de choisir une structure de données, la place qu'elle occupe en mémoire peut également être décisive si vous stockez vraiment une grosse quantité de données. En règle générale, la différence n'est pas suffisamment importante d'une structure à l'autre pour que l'on prenne la peine de s'en soucier (les performances avant tout, n'est-ce pas), mais dans les situations extrêmes de beaucoup beaucoup d'octets à manipuler, on devra commencer à prendre des pincettes. Mais c'est également dans ce cas qu'on finira peut-être par développer ses propres structures de données aux petits oignons, si on en est là. Dans tous les cas, la structure de données qui occupe le moins de place en mémoire est le tableau, eh oui, bravo à lui. Comme quoi c'est tout de même un camarade bien gentil, malgré ses quelques défauts par ailleurs.



Tu les ranges tes données ?


Allez, il est temps de nous lancer dans un grand top 50, mais avec moins d'entrées au hit-parade quand même, des structures de données élues plus vertes de tous les temps par SourisMag. Bon, à vrai dire il existe tout un tas de structures très exotiques que nous garderons sous silence (arbres de plein de variétés, graphes, etc), pour nous contenter des structures les plus simples et les plus fréquemment utilisées. Nous allons également discuter des points forts et des points faibles de chacune, histoire de bien comprendre ce qui doit guider nos choix.



1 - Il est beau mon tableau


On commence par celui que nous connaissons tous, la structure universelle que même le VisualBasic de tonton doit savoir manipuler (enfin je dis ça, je m'avance peut-être), à savoir le tableau. Simple, élégant de bon, goût, le tableau est une structure formidable quand elle est implémentée par une vraie série de cases contigues en mémoire, jugez plutôt :


Plein d'avantages :

- c'est la structure la plus économe en mémoire

- c'est la structure la plus rapide à énumérer. Il ne faut qu'une seule opération pour passer d'un élément au suivant, et si en plus le tableau est tout entier dans le cache processeur ou dans la page de mémoire vive courante, on vole à la vitesse du vent

- c'est aussi la structure la plus efficace pour atteindre un élément donné si on connaît sa position : une seule opération, là encore, avec la même remarque que précédemment si le tableau est déjà chargé en mémoire


Mais des inconvénients :

- atteindre un élément dont on connaît la valeur, mais pas la position, demande d'énumérer tous les éléments. Coût de l'opération : de l'ordre de N instructions pour un tableau de taille N.

- c'est une des structures qui a le plus fort coût à l'insertion d'un élément. Si on l'ajoute à la fin et qu'on a alloué la place mémoire pour l'élément en trop, aucun problème. Par contre, ajouter un élément ailleurs nous oblige à décaler tous les éléments. Si jamais on a plus de place pour mettre un élément en plus, il faut allouer un tableau plus grand et tout recopier, bonjour le nombre d'opérations. Dans tous les cas l'insertion d'un élément coûte l'ordre de grandeur du nombre de valeurs dans le tableau.

- la suppression d'un élément est encore pire, sauf si là encore c'est le dernier. Dans tous les autres cas, c'est recopie de tous les éléments vers la gauche, sans possibilité de désallouer la mémoire inutilisée, sauf à tout recopier ailleurs, et là encore on paie environ N éléments en ordre de grandeur pour un tableau de taille N, sans compter la mémoire dépensée le temps de réaliser la copie. Eh oui ma bonne dame.



2- La liste déchaînée


Autre candidat bien sympathique parmi les structures toutes élémentaires, qu'on peut réimplémenter soi-même dans son salon sans risquer d'affreux plantages De La Mort, j'ai nommé la liste chaînée, sous vos applaudissements. Elle est toute simple : chaque élément contient une valeur, et un pointeur vers l'élément suivant. Facile, non ?


Des avantages à gogo :

- une efficacité redoutable pour énumérer tous les éléments, par petits sauts de puce de pointeur en pointeur. Pas tout à fait aussi véloce que le tableau, mais l'ordre de grandeur pour atteindre chaque élément depuis le précédent est d'une opération aussi.

- c'est une structure pas totalement, mais quand même relativement, efficace pour l'insertion d'un élément, où qu'il soit. En fait, il faudra compter de sauter jusqu'à l'élément où vous voulez ajouter un copain, donc plus il est loin du début, plus vous payez. Une seule instruction si vous insérez systématiquement en début de file, mais de l'ordre de N instructions si jamais vous allez n'importe où, c'est moins super.

- même chose pour la suppression, opération élémentaire, qui ne demande que de localiser l'élément en question.


Mais aussi des inconvénients quand même :

- on l'a déjà dit, atteindre un élément donné, par sa position comme par sa valeur, nécessite de suivre toute la liste, donc un ordre de grandeur de N opérations. Bof bof.

- cette structure occupe davantage de place en mémoire que le tableau, puisqu'en plus de la valeur on stocke l'adresse de l'élément suivant. Pas forcément énorme, mais ça peut commencer à saler l'addition si on a vraiment une grosse structure à maintenir.


Il existe une variante tout aussi rigolote, appelée la liste doublement chaînée, où, pour chaque élément, on stocke un pointeur vers l'élément précédent en plus du suivant. Dans ce cas on peut parcourir facilement la liste dans les deux sens, et insérer aussi facilement en début qu'en fin de liste. Pratique, mais là encore il y a un surcoût en mémoire.



3- En file indienne


Ah ah, ici on commence à rencontrer des structures un peu plus élaborées qui vont nous servir dans des situations très pratiques. Reconnaissons-le franchement, si on utilise des tableaux de manière courante, on ne va pas souvent sortir des listes chaînées de notre chapeau, sauf pour un exercice scolaire de programmation. Par contre la file, ça oui, on en voit partout et tout le temps. Dès qu'on fait communiquer deux machines/programmes/souris entre elles/eux, on a besoin d'une petite file : une structure où on empile d'un côté, et on dépile de l'autre, comme ça on prend toujours les éléments dans leur ordre d'arrivée, et on évite de mettre un joyeux désordre dans notre communication.


Alors, en fait la file en tant que telle peut être implémentée de plein de manières, mais si vous avez bien suivi ce qui précède, vous voyez que la plus efficace de loin est la liste doublement chaînée, puisque les opérations que l'on privilégie sont l'insertion en début et la suppression en fin de file. On peut s'en sortir aussi avec un tableau de taille variable, mais c'est à condition de connaître à l'avance la taille maximale du nombre d'éléménts qu'on peut mettre dans notre structure.


Pourquoi elle est gentille :

- insérer et supprimer un élément aussi bien en début qu'en fin de file ne nous coûte qu'une seule instruction machine, formidable.

- récupérer tous les éléments un à un à la suite est très efficace, même si ça n'est généralement pas pour cela qu'on choisit une file.


Pourquoi elle est méchante :

- l'insertion ou la suppression en milieu de file est totalement prohibée. Elle serait théoriquement possible, mais avec un surcoût non négligeable, et de toute manière c'est en contradiction flagrante avec la finalité même de la structure, donc souvent cette opération n'est même pas disponible.

- aller inspecter la file pour voir si une valeur précise y est stockée demande d'énumérer tous les éléments, donc de l'ordre de N instructions pour une file de taille N. Et là encore, cette possibilité n'est pas toujours offerte à l'utilisateur sympathique.



4- Remonté comme une pile


Autre structure à inclure dans sa petite besace, largement sous-estimée et trop peu utilisée à notre goût, la pile est votre amie dès lors qu'il s'agit ranger nos éléments pour ressortir toujours du tas le dernier déposé. Notez bien la différence avec la file, qui elle prend toujours l'élément le plus ancien encore disponible.


Par ailleurs, la pile est absolument indispensable dès que vous faites des parcours d'arbres en profondeur, ce que vous faites, si si, dès que vous parcourez une arborescence de fichiers. Si vous ne vous en rendez pas compte la plupart du temps, c'est que vous utilisez la pile d'appels de votre langage de programmation, en lieu et place de la votre propre.


Disons le franchement, elle regorge de qualités :

- l'insertion et la récupération d'un élément est simplissime, une seule minuscule instruction

- c'est une structure excessivement économe en mémoire, en tout cas quand elle est correctement implémentée

- l'énumération (enfin, le dépilement) de tous les objets dans la pile est très efficace


Mais elle a quand même quelques défauts :

- impensable d'insérer ou de retirer un élément ailleurs qu'au début, sans quoi elle perd tout son intérêt

- savoir si une valeur est présente dans la pile nécessite d'en énumérer tous les éléments un à un, donc de l'ordre de N instructions. Et encore, ceci n'est pas toujours possible sans dépiler puis réempiler tout le bazar.



5- Tout en gros tas


Moins connu du grand public, et très honnêtement assez difficile à trouver sur le marché aux structures incluses dans les librairies courantes, le tas est pourtant bien pratique dans certaines situations. Il faut dire aussi que son nom n'est pas très vendeur non plus, aux souris vertes on l'appelle souvent le Gros Tas, même si on a beaucoup d'affection pour lui.


Alors, le tas sert à entasser, eh oui, toutes nos petites données en leur accolant un poids. Plus la donnée pèse lourd, plus elle part au fond du tas. Et on peut ainsi récupérer en une seule instruction la donnée la plus légère, puis la suivante, etc. Il existe une variante également où c'est le plus lourd que l'on ressort à chaque fois ; bon, même si ça n'est pas disponible il suffit d'affecter l'opposé de nos poids pour que ça fasse la même chose, remarquez bien.


Une formidablitude non démentie :

- il faut une seule opération pour obtenir le minimum (ou le maximum) de notre structure. Attention cependant, comme l'insertion d'un élément n'est pas la plus économe, construire un tas juste pour trouver le minimum de N valeurs est moins efficace que d'énumérer simplement les valeurs en gardant la plus petite.

- l'énumération des valeurs successives ne coûte rien, et en prime on vous les renvoie dans l'ordre croissant des poids. Le tas fait donc partie des structures optimales pour trier des données, et est utilisé par un certain nombre d'algorithmes de tri

- voir si une valeur existe dans le tas est très rapide, de l'ordre de log(N) opérations pour un tas de taille N.

- l'insertion et la suppression d'une valeur est également relativement efficace, de l'ordre de log(N) opérations


Mais pas que non plus :

- ben, en fait, on pourrait remettre ici tous les points précédents : insertion, suppression, lecture d'une valeur, sont efficaces, c'est vrai, mais il existe des structures bien plus rapides pour chacune des ces opérations. Le tas est plutôt bon partout, mais il n'excelle nulle part.


En pratique, il n'y a pas de mystère, si le tas n'est pas utilisé de manière courante, c'est qu'il ne se démarquera de ses petits copains que dans des cas très spécifiques, et que pour l'écrasante majorité des cas il y aura toujours une structure plus adaptée. Mais ça reste souvent un bon deuxième choix si aucune implémentation d'une structure que vous souhaitiez n'est disponible.



6- En finesse mais à la hache


Nous avons gardé le meilleur pour la fin. Il existe toute une classe de structures qui s'appuient sur des fonctions de hachage pour vous offrir une efficacité redoutable sur certaines opérations très courantes. La structure algorithmique sous-jacente s'appelle une table de hachage, mais elle permet d'implémenter dictionnaires, ensembles, tableaux associatifs et sans doute encore d'autres structures que nous oublions au passage.


Le principe est toujours le même : grâce aux fameuses fonctions de hachage sorties du cerveau brumeux de mathématiciens déchaînés, nous sommes en mesure d'accéder à une valeur donnée de notre ensemble en une seule opération. Oui, une seule, et ceci quel que soit l'élément et quelle que soit la taille de votre ensemble. Vous pouvez vous pincer, vous ne rêvez pas. Alors, tout ceci n'a pas que des avantages, ça serait trop facile, et il va falloir payer du gros coût à la sortie sur certaines opérations. En général, nous utilisons ces structures pour stocker des ensembles (clé, valeur), on donne la clé et on retrouve la valeur en une seule opération rapide comme l'éclair.


Que de délices nous attendent :

- nous venons de le dire, une seule opération pour l'accès à un élément donné en connaissant uniquement sa clé associée.

- une seule opération aussi pour insérer et supprimer une clé de notre paquet

- une seule opération pour répondre à la question : ma clé est-elle dans mon gros tas ? Du coup c'est très utile pour dédoublonner des valeurs dans un ensemble : on pose tout dans notre dictionnaire / ensemble / table de hachage, et à l'arrivée l'ensemble des clés ne contient que des valeurs uniques.


Mais attention l'addition est parfois salée :

- commençons tout de suite par ce qui fâche, à savoir l'énumération des éléments qui est tout simplement misérable. Nous trouvons ici de très loin la structure la plus lente pour énumérer les éléments les uns après les autres, un phénomène dont bien peu de programmeurs semblent avoir conscience, qui mettent tout ce qu'ils ont sous la main dans une table de hachage uniquement pour la parcourir entièrement à la fin. Croyez-moi, la différence avec un tableau est tout simplement abyssale si la structure est de grande taille.

- la structure demande plus de place en mémoire que la plupart des autres structures élémentaires énumérées ici. Bon, rien d'incroyable non plus, surtout si elle est bien implémentée, mais dans certains langages où ça n'est pas le cas, la place occupée en mémoire peut devenir assez vite gênante.

- les opérations élémentaires demandent en moyenne une instruction, c'est vrai, mais il s'agit tout de même d'un calcul de hash qui est nettement plus qu'un simple accès à un élément dans un tableau par sa position. Donc une GROSSE instruction, quand même, et qui sollicite gentiment le processeur au passage.

- dernier point, si les hashs sont mal distribués, c'est-à-dire si la fonction de hachage utilisée ne se comporte pas très bien avec les données que vous stockez, eh bien là les ennuis commencent sérieusement et la structure devient aussi gracile qu'un éléphant cherchant à faire du skateboard. Le risque est minime tant que la taille de la structure reste limitée, mais si vous commencez à y jeter plusieurs millions d'entrées, il va sans doute falloir y regarder de plus près sur la manière dont la structure est implémentée dans les coulisses.


Mais cette dernière remarque est finalement valable pour n'importe quelle structure : si vous dépassez une taille critique, disons plusieurs centaines de milliers d'entrées, vous pourrez rarement vous contenter de l'implémentation standard à portée de main, et il vous faudra sans doute, soit la paramétrer finement, soit en modifier le code, soit carrément repartir de zéro pour écrire la votre à la place.


Alors, attention tout de même, tout ce qui brille n'est pas or, et tous les langages qui proposent des structures associatives ne les implémentent pas forcément de manière efficace. Aux Souris Vertes, par exemple, on se gausse régulièrement, mais gentiment, du gros éléphant PHP, un des langages pourtant les plus utilisés au monde, qui propose des tableaux associatifs qui ne sont efficaces ni comme tableaux, ni comme structure d'association. Une belle prouesse !


Halte au maintien de l'ordre

Il existe évidemment des milliards de millions d'autres structures de données qui peuplent l'univers de l'informatique moderne. Parmi celles-ci, il y en  qui nous laissent franchement perplexes aux souris vertes, à savoir celles qui maintiennent un ordre naturel des éléments : une liste ou un tableau triés, une map ordonnée (comme une table de hachage dont on peut énumérer les clés dans l'ordre croissant), etc.

Entendons nous bien, le fait d'avoir des données triées permet d'accélérer notablement certaines opérations, comme le fait de trouver un élément en log(N) par exemple au lieu de N essais. Mais, généralement, le fait de devoir maintenir l'ordre à l'insertion et la suppression de valeurs coûte bien plus cher que le fait de tout ranger sans se poser de question et de retrier ensuite. Donc, à moins d'avoir absolument besoin de l'ordre des éléments entre deux insertions, on sera bien inspiré de se tenir loin de ces structures qui ont l'air toutes bien rangées, mais sont sous-optimales pour pratiquement toutes les opérations (insertion, suppression, récupérer une valeur, etc).


Soigner son langage


Bien, nous en avons terminé de notre petit tour d'horizon des plus belles structures de données de la collection automne-hiver de l'année.  Nous ne pouvons que vous inviter à  découvrir par vous-même tous les autres trésors que nous n'avons pas abordés ici, sachant que plus vous choisirez une structure adaptée à vos besoins, plus votre code sera performant et votre impact en mémoire ou en stockage limité.


Mais, en pratique, on ne peut pas non plus occuper son temps éveillé à implémenter des structures de données, donc on est bien souvent contraint de s'appuyer sur celles qui sont disponibles de base dans le langage de programmation que nous utilisons. Arrivé à ce point de notre réflexion, on se rendra vite compte que tous les langages ne sont pas équivalents, non non non, et que s'il faut un critère pour les discriminer, au-delà des Super Benchmarks De La Mort qui vous démontrent que X lave plus blanc car il calcule des fractales à la vitesse du son, on sera bien inspiré de regarder si ledit langage possède des structures de données bien implémentées et adaptées à toutes les situations.


En général, quel que soit le langage utilisé, on essaiera d'avoir au minimum deux structures toujours sous le coude : un bon vieux tableau, ou liste, pour les traitements qui demandent des énumérations fréquentes, et une table de hachage, ou équivalent, pour tout ce qui demande des accès par valeur, ou du dédoublonnage. Muni de ces deux outils de base, et en choisissant systématiquement celui qui va le mieux, nous sommes déjà en mesure d'écrire du code quasi optimal dans toutes les situations courantes. Si en plus, on a gardé en tête les conseils de notre dernier article, et qu'au lieu de spammer notre base de données, on monte en mémoire une structure qui nous permet de les interroger de la manière la plus efficace possible tout au long de l'exécution de notre programme, on aura largement mérité d'encadrer notre diplôme de Programmeur Responsable (TM) au-dessus du canapé de notre salon.



Mais t'arrêtes donc de recopier, toi ?


Une dernière remarque, et après promis on s'arrête là pour aujourd'hui, car les souris piétinent d'impatience à mes côtés, il y a une chose qu'il faut absolument contrôler lorsque vous utilisez un langage de programmation, c'est la manière dont sont passés les paramètres des fonctions. Il y a en fait deux possibilités :

- les paramètres sont passés par référence, c'est-à-dire qu'on vous donne un pointeur sur l'objet que vous aviez passé, et que votre fonction peut le modifier à loisir, vous récupérez ensuite l'objet modifié

- les paramètres sont passés par valeur, autrement dit vous en avez une copie toute neuve dans votre fonction que vous pouvez triturer à l'envi, l'appelant n'en saura rien, le coquin.


Aucune des deux méthodes n'est universellement satisfaisante, car parfois vous aimeriez bien que la fonction appelée n'aille pas mettre en bazar tout ce que vous lui envoyez, et en même temps si vous avez une structure géante, vous ne voulez pas forcément la recopier entièrement de fonction en fonction.


Les langages les mieux conçus passent généralement les types primitifs (entiers, chaînes de caractères, etc) par valeur, et les objets plus complexes par référence, mais certains ont le mauvais goût de tout passer par valeur si on ne leur dit rien, et alors là bonjour les dégâts : dès que j'appelle une fonction, c'est recopie à gogo, donc grosse perte de temps et de mémoire. Pour ceux-là, on forcera systématiquement le code à passer nos structures de données par référence. Et si cela n'est pas disponible, fuyez le langage en question comme la peste !



Nous voici au bout de notre exploration curieuse et étonnée des structures de données en mémoire. Nous espérons n'avoir pas trop fatigué les lecteurs avec ces considérations qui peuvent avoir l'air de détails microscopiques , mais qui sont essentielles à nos yeux pour réduire le gaspillage informatique planétaire. Les souris sont déjà en train de courir dans le jardin, aussi je tire ma révérence en vous laissant vous délasser l'esprit sur un petit haïku final :

"Dans son écorce
Le chêne
Garde la mémoire de mon regard"

Midoriro no Mausu (la Souris Verte)

>Voir le billet et ses commentaires...
 

Le Petit Geste De La Rentrée : j'arrête le streaming
Date 10/09/2017
Ico Le Petit Geste du Jour
Comms Aucun commentaire

Le petit geste du jour

"Boue

Qui s’écoule

S’éclaircit"


Taneda Santoka (1882-1939)


Youpi ! Les souris vertes bondissent hors de leur tannière et saluent bien bas leurs fidèles lecteurs dans un retour son et lumière fracassant. Il est temps en effet pour elles d'interrompre leur retraite pour venir nous dispenser à nouveau ces conseils si sages dont elles ont le secret, elles qui étaient reparties tranquillement vaquer à leurs occupations de petits muridés avec la conscience du devoir accompli et la certitude que le monde avait entendu leur message. Mais le monde est-il sauvé pour autant ? Les déluges d'octets inutiles se sont-ils enfin taris ? La forêt amazonienne est-elle enfin libre de se régénérer, les mines à ciel ouvert sont-elles enfin fermées face à tous ces datacenters que l'on ne construira plus, toute cette énergie que l'on ne gaspillera plus ?


Que nenni. Au contraire, pendant que nous paressions doucement au rythme des nuits d'été, les projets avancent à grands pas pour nous promettre toujours plus de réseaux déployés, 4G, 5G et tous les G qu'on voudra, nouveau système GPS européen (on ne va tout de même pas laisser les Américains avoir le dernier mot, non ? Nous aussi on peut lancer des centaines de satellites en orbite pour localiser l'entrée d'autoroute ou le salon de coiffure le plus proche), tablettes par millions dans les établissments scolaires, et sans doute beaucoup d'autres bonnes idées qui nous offrent un horizon radieux de consommation d'octets sans besoin.


Il est donc temps pour notre joyeuse équipe de ressortir le bâton de pélerin pour aller prêcher la Bonne Parole Numérique dans un monde où adultes comme enfants ne souhaient vraiment pas entendre qu'il faudrait fermer un peu le robinet numérique. Et pour la rentrée, on attaque de front un sujet qui fait bien mal à la planète malgré son apparente innocuité, j'ai nommé le Vilain Streaming.


Octet, suspends ton vol


Qu'est-ce donc que cet objet au nom barbare que nous nous proposons d'étudier aujourd'hui ? Une technique de saut à ski ? Une méthode de composition de musique électronique ? En tout cas c'est nécessairement très moderne et chic, vu qu'on n'a pas trouvé de manière de traduire cela dans notre bonne langue françoise. Si l'on s'en tient au dictionnaire, cet étrange vocable désignerait dans la langue du Cheikh Spire un flux, ou plutôt quelque chose qui coule à flots. Et c'est bien de flots, gros bouillons et vagues géantes qu'il s'agit, comme nous allons le voir présentement.


En vérité, le streaming est cette petite pratique anodine qui consiste à regarder du contenu multimédia directement à travers le réseau, dans son navigateur ou à l'aide d'une application dédiée. Il n'est pas inutile de rappeler que, bien qu'il se soit répandu comme une traînée de poudre et paraisse aujourd'hui aussi naturel que l'air qu'on respire, cet usage est excessivement récent et aurait été bien impossible à réaliser techniquement il y a plus d'une dizaine d'années. Grâce à une ingénierie toujours plus fûtée et des tuyaux informatiques toujours plus gros, nous sommes maintenant en mesure de réaliser cette prouesse les doigts dans le nez et les yeux fermés, du soir au matin, et ainsi de regarder un film ou d'écouter une musique qui se trouvent stockés à des milliers de kilomètres. Formidable !


Malheureusement, comme beaucoup de promesses numériques qui semblent fleurer bon la liberté insouciante du consommateur ravi, cette proposition apparemment charmante cache un squelette de taille conséquente dans le placard (la taille mammouth plutôt que petite souris verte, dieu merci pour elles). Pour le dire sans détour, le streaming est probablement ce que l'on a inventé dernièrement de plus intense en consommation de ressources de tout poil : réseau, stockage, temps processeur, tout y passe, et pour une fois d'ailleurs, aussi bien sur les gros serveurs mondialisés que sur votre petit ordinateur personnel. Comment est-ce donc possible ? Allez, changeons de paragraphe pour essayer de comprendre tout cela.


Difficulté de la livraison à domicile


Que se passe-t-il rééllement lorsque nous appuyons innocemment sur le petit bouton pour lancer la vidéo qui créé le buzz du moment ? Eh bien, c'est le branle-bas de combat du côté du serveur GoopleSoftBook que nous interrogeons, car il doit se préparer à servir pendant une durée importante du contenu multimédia bien volumineux. Après quelques échanges de politesse avec votre ordinateur (ou tout appareil numérique de votre choix qui permet ce haut niveau de technologie), le serveur va vous dispenser la vidéo par petit morceau, pendant que vous les regardez au fur et à mesure. Et c'est là que le numéro de funambuliste est particulièrement délicat, car il s'agit de faire en sorte que votre lecture ne s'interrompe pas en permanence pour attendre le petit morceau suivant, sans quoi vous allez vite vous lasser et retourner à la cueillette de champignons sans avoir vu ce petit numéro burlesque que tout le monde s'arrache ces jours-ci, ou plutôt ces heures-ci.


Vous comprenez maintenant la difficulté que pose le streaming, qui doit assurer une lecture continue dans des conditions adverses où tous les paramètres sont fluctuants (bande passante réseau, latence avec les différents utilisateurs, activité des serveurs, nombre de personnes demandant la même vidéo, paquets perdus, etc). Dans ces conditions, on ne peut que saluer l'inventivité des informaticiens qui ont permis ces prouesses par des techniques de transfert toujours plus sophistiquées. Mais en vérité, bien plus qu'au génie de l'humanité, c'est surtout au fait qu'on ne compte pas à la dépense qu'on doit cette belle réalisation. Le streaming impose des exigences sur la qualité des liens réseaux et la taille des gros tuyaux de communication sans commune mesure avec toute autre utilisation d'internet, et c'est bien pour cet usage seul qu'aujourd'hui on nous vend toujours plus de bande passante, de la 15G et des connexions par la fibre optique toujours plus mirifiques. Car, sachez-le, le fait de relever son courrier électronique ou de consulter l'extraordinaire blog des souris vertes, même 100 fois par jour, ne permettraient pas cette escalade numérique du Besoin qui Grossit. C'est bien la promesse de la télévision par internet, de la vidéo à la demande, de l'écoute musicale illimitée qui nous pousse vers cet avenir radieux.


Une petite souris à ma droite me demande d'enfoncer encore un peu le clou. Il faut dire qu'aux Souris Vertes, nous sommes positivement effrayés par le développement incontrôlé du Streaming Partout, car nous y voyons le futur de ces milliers de datacenters qui consomment plus que des villes (occidentales) de 50 000 habitants pour le plaisir relatif de passer son temps à voir du contenu marrant ou curieux, autant dire toute expérience que vous auriez pu faire à moindre frais en vous asseyant un moment sur le premier banc public venu. Ah oui, le clou, le clou, on me rappelle en me mordillant la jambe.


Bon, résumons donc, le Streaming c'est mal, vilain et méchant tout à la fois parce que :

- ça nécessite des infrastructures réseau De Maboul, avec des liens de qualité incroyable, et ce jusqu'à votre salon (donc votre propre connexion internet doit être bien robuste).

- ça entraîne des besoins de stockage pharaoniques, pour stocker ces petites vidéos que vous filmez en un clin d'oeil sur des dizaines de serveurs différents afin qu'elles soient disponibles de partout et pour tous.

- ça demande des serveurs particulièrement performants et en grand nombre, capables de servir du contenu multimédia à tout moment et quel que soit le nombre de personnes en demande.

- ça met un serveur distant et votre ordinateur en état d'alerte maximal pendant la lecture multimédia : la gestion casse-tête par petits paquets et la décompression des flux fait bien travailler les processeurs.

- ça occupe la majeure partie de la bande passante réseau internet. Pour une vidéo regardée ou un disque écouté, vous consommez sans doute plus que le reste de votre consultation internet mensuelle, voire annuelle en fonction du format de compression. Eh oui.


Conclure sans désespérer


Gloups. Décidément, le Professeur Souriso continue à nous étonner par l'universalité de sa maxime dans le domaine numérique, "Petit Confort entraîne Grosse Dépense". Elle est d'une acuité particulière quand il s'agit de parler du streaming, car si on se gardera bien de mesurer le confort additionnel que vous apporte cette innovation fascinante (les souris vertes cachent bien leur enthousiasme, mais elles ne représentent pas forcément la majorité des habitants de la planète sur ces questions), on voit que côté dépense à gogo, le streaming se pose là. En terme de gaspillage de ressources informatiques, c'est sans doute le candidat le plus prometteur des années à venir.


Que faire donc ? Allons nous donc nous interdire de regarder des vidéos ou d'écouter de la musique sur internet ? A vrai dire, baisser un peu la consommation frénétique de contenu multimédia serait sans doute une bonne idée, surtout quand on a déjà tant d'autres moyens d'y avoir accès (cinéma, médiathèque, prêt entre amis, etc). Et passer un peu moins de temps à regarder des écrans et un peu plus à regarder les nuages serait sans doute bénéfique aussi bien aux personnes qu'à la planète. Mais, il est vrai qu'il serait dommage de se priver totalement de toute cette richesse de ressources disponibles à travers nos réseaux. Dans ce cas, et sans hésitation, on choisira dès que possible de télécharger le contenu pour le visionner sur sa machine. Ceci consommera de la bande passante, bien sûr, mais pendant un temps bien plus court et avec des contraintes sur la qualité des réseaux nettement moindres, sachant que vous saurez prendre votre mal en patience si le fichier met quelques secondes ou minutes de plus à se télécharger qu'à un autre moment.


Bien évidemment, le fait de parler de téléchargement n'est pas un appel vibrant au piratage de contenu de tout poil, sachant qu'aux souris vertes on considère que tout travail de qualité mérite rémunération, et que tout ce qui est gratuit sans être explicitement offert est généralement suspect de coûts cachés que vous assumez par ailleurs, en terme fiscal, social ou environnemental. Cela dit, pour les grand sites de streaming qui semblent s'assoir assez gentiment sur les notions de droits d'auteur, on pourra leur rendre la monnaie de leur pièce en trouvant des convertisseurs qui permettent de rapatrier le contenu multimédia sur votre machine et au format que vous préférez. Il en existe même en ligne, comme celui-ci par exemple. Cette solution n'est pas optimale car on fait alors travailler un deuxième serveur pour notre besoin, mais si on en garde un usage raisonnable on peut très bien s'en contenter.


Bien, il est temps de se quitter sur ce Petit Geste de rentrée des classes d'une efficacité remarquable dans la préservation du futur de l'espèce humaine et du reste de la galaxie. On remercie bien fort la souris vertes à lunettes pour son choix éditorial de rentrée d'une grande pertinence, et on acclame toutes nos gentilles souris qui courent rejoindre leur petit pré, en attendant avec impatience d'autres discussions passionnantes pour sauver le monde !










>Voir le billet et ses commentaires...
 

Le Petit Geste Du Jour : j'écris un haïku pour me détendre
Date 06/05/2017
Ico Le Petit Geste du Jour
Comms 1 commentaire

 



Tiens, aujourd'hui pour changer, on ne parlera pas de numérique, de réseaux, de gros câbles, ni d'antenne Oui-fils. Et pour couronner le tout on ne commence même pas par un haïku ! Tout ceci pour une bonne raison, puisque l'on se propose présentement de faire un Petit Geste en forme d'atelier d'écriture.


Aux Souris Vertes, de manière générale, on encourage les gens à faire-le-soi-même, alors on ne va pas se cantonner aux domaines habituels de la réparation informatique d'urgence ou de l'utilisation experte d'applications de tout poil, et on va vous lancer dans le grand bain en vous proposant d'écrire vous-même votre petit haïku du jour. Qui sait, peut-être même va-t-on bientôt demander à nos lecteurs d'illustrer les articles par leurs propres dessins, ce qui ne serait pas du luxe vu la flemme que votre serviteur entretient pour tailler ses crayons de couleur en ce moment, voire d'écrire eux-mêmes les articles ! Bon, pour le moment on va se calmer et en rester bien gentiment au haïku.


Oui, pourquoi toujours déléguer ce petit instant de fraîcheur à une ou deux souris volontaires, quand vous pouvez-vous aussi apporter votre petite touche personnelle de description du monde ? Alors la marche à suivre pour ce faire est d'une simplicité extrême :

- se munir d'un papier et d'un stylo

- écrire trois vers qui ne riment même pas

Et voilà ! En vérité en japonais il s'agit d'un seul vers en 3 parties à la métrique parfaitement codifiée, mais vu que le passage en français entraîne toujours débordement et absence totale de règle dans les sonorités et le rythme des phrases, on peut y aller gaiement et à pieds joints.


Enfin, je dis ça, mais j'espère que la Ligue de Protection du Haïku ne va pas nous tomber sur le dos, car nous n'avons suivi aucun cursus universitaire en la matière et nous contentons de relayer les quelques conclusions que nous avons pu tirer de nos lectures au coin du feu.


Voilà donc un petit geste diablement simple et qui ne coûte pas un roupie. Et soyez assuré qu'il est tout aussi salutaire que ceux que nous égrainons patiemment au fil de nos articles : non seulement, pendant que vous écrivez votre petit haïku, vous n'êtes pas en train de consommer de l'octet au quintal ou de faire toute autre activité qui a pour corollaire distant la déforestation de l'Amazonie et l'extinction des espèces marines, mais en plus cette petite gymnastique a un effet bénéfique immédiat de détente et de bien-être. Et l'on sait bien que le stress et la vie dans la course permanente constituent le carburant idéal pour consommer puis jeter toujours plus.


Cerise délicatement posée en équilibre sur le gâteau, vous vous rendrez rapidement compte qu'avant d'écrire, il va vous falloir vous arrêter pour observer : de par sa brièveté, le haïku nous invite à condenser une expérience intime et subtile ; qu'il s'agisse de décrire quelque chose que l'on voit, entend, ou ressent, il va falloir un petit travail d'introspection et d'écoute de soi et du monde pour réussir à mettre des mots là où il n'y avait rien que du perçu.


Bref, c'est pour nous une très bonne école d'éducation à l'environnement et à l'écoute du monde vivant comme de la société. Rien que ça.


Nous terminons en lançant un appel vibrant à nos fidèles lecteurs pour que notre formidable webmaster n'ait pas travaillé sur sa belle fonctionnalité de commentaires pour des prunes, alors venez contribuer sans retenue de votre petit poème ! Une fois de plus, les Souris Vertes donnent l'exemple en essayant de vous faire partager un de nos grands ravissements, à savoir le fait de regarder le ciel de sous un tilleul. Oui oui, cela fonctionne même sous les pauvres arbres qui bordent les avenues et qui sont régulièrement martyrisés par les services municipaux des espaces verts.


On y va pour notre Petit Geste :

"Sous le tilleul

Je lève les yeux

Eclat de lumière verte"


Midoriro no Mausu (la Souris Verte)








>Voir le billet et ses commentaires...
 

1 2 3 4 ... 8

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