Convertir des Mio en ko

Un mébioctet vaut 1 024 kibioctets, soit 1 048 576 octets. Les outils Linux et les chiffres de mémoire désignent presque toujours cela, même quand ils écrivent « Mo ».

Un kilooctet vaut 1 000 octets quand c’est un organisme de normalisation qui le définit, et 1 024 quand c’est un système d’exploitation. Cette page compte en 1 000 ; l’unité valant 1 024 s’appelle kibioctet.

Le facteur vaut 1048,576, et à peu près personne ne le trimballe. Arrondi à 1050, il s'écarte de 0,14 % — invisible sur de petits nombres, et devenu une unité entière vers 1 000 MiB.

C'est ce chiffre-là qu'il faut connaître avant d'arrondir : pas l'erreur elle-même, mais l'endroit où elle cesse d'être négligeable. En dessous, le facteur court est le bon choix ; au-dessus, servez-vous du champ ci-dessus, qui n'arrondit qu'au moment d'afficher.

Un MiB vaut 1 024 fois l'unité du dessous ; un MB, 1 000. Sur cette page, c'est l'écart entre 1048,576 kB et 1000 kB — 4,9 % — et il grandit à chaque palier : négligeable sur une photo, visible sur un disque dur.

Le mystère de l'espace disque manquant tient tout entier là-dedans, et sur cette page il vaut 4,9 %. Un disque vendu en MB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 1000 kB là où la boîte annonçait 1048,576 kB. macOS compte ces tailles en unités décimales depuis 10.6, d'où le même disque qui paraît de deux tailles sur deux machines — rien n'a disparu et personne n'arrondit : les mêmes octets portent deux noms.

L’outillage de build compte en binaire parce qu’il décrit ce que contient un système de fichiers, et un assembleur qui imprime Kio et Mio l’a dit honnêtement. Les budgets de performance sont écrits en kilooctets décimaux parce qu’ils décrivent des octets qui traversent un réseau, où les puissances de dix sont la convention depuis bien avant que quiconque n’expédie un mégaoctet de JavaScript. Les deux sont cohérents en interne et ne s’accordent pas entre eux.

La conversion est une multiplication par 1 048,576. Un paquet rapporté à 1,5 Mio fait 1 572,9 ko, et non 1 536 ni 1 500. Face à un budget de 1 500 ko il dépasse de près de cinq pour cent, et la conversion ronde dans la tête de quelqu’un est précisément ce qui le cache — 1,5 Mio se lit « environ un mégaoctet et demi », ce qui semble tenir.

Avant de se soucier de 4,9 %, vérifier que le chiffre mesure la bonne chose. Un outil de build rapporte la taille du fichier qu’il a écrit ; un utilisateur attend les octets compressés qui ont traversé la connexion. Les actifs textuels se compressent en général entre un cinquième et un quart de leur taille brute, de sorte qu’un paquet de 1,5 Mio peut faire 350 ko sur le fil, et un budget écrit sur le chiffre brut est décalé d’un facteur, pas d’un pourcentage.

Cela ne rend pas la conversion d’unité inutile — le chiffre compressé doit bien être énoncé dans une unité, et le même 2,43 % s’y applique. Cela clarifie l’ordre des opérations : établir à quel étage du pipeline le chiffre correspond, puis convertir son unité. Avoir raison sur la deuxième et tort sur la première produit un nombre énoncé avec précision sur la mauvaise quantité.

Une erreur de mesure aléatoire s’équilibre sur suffisamment d’actifs ; une erreur d’unité ne le fait pas, parce que c’est la même multiplication à chaque fois et toujours dans le même sens. Chaque actif paraît un peu plus petit qu’il n’est, le total paraît un peu plus petit qu’il n’est, et chaque comparaison au budget est un peu optimiste. Rien dans le rapport n’a l’air faux, et la réconciliation n’échoue que face à des données de terrain collectées par quelque chose qui mesurait des octets.

La composition est ce qui transforme la pédanterie en écart réel. Une page assemblée à partir de vingt actifs, chacun converti avec le facteur rond, est en déficit de 2,43 % au total — peut-être trente ou quarante kilooctets sur une page moyenne. C’est à peu près la taille d’une petite bibliothèque entière, ce qui est le genre de chose que les équipes passent un après-midi à retirer. La comparaison vaut la peine d’être faite explicitement quand quelqu’un propose de resserrer un budget : une conversion correcte récupère le même nombre de kilooctets qu’une vraie optimisation, et elle prend une ligne d’arithmétique plutôt qu’un refactor.

Les deux montreront rarement le même chiffre pour le même actif, et les raisons s’accumulent. Le rapport de build montre les octets bruts en unités binaires ; le panneau réseau montre les octets transférés, compressés, en unités décimales, et peut inclure ou non les en-têtes de réponse. N’importe laquelle de ces différences suffit à faire diverger les chiffres de dizaines de pour cent, et les trois ensemble rendent toute comparaison directe dénuée de sens.

La façon de les comparer consiste à ramener les deux à un compte d’octets de la même quantité. Prendre l’artefact compressé, lire sa taille exacte, et la comparer à la taille transférée que rapporte le navigateur ; le résiduel devrait être petit et attribuable à la surcharge protocolaire. Une fois que ceux-ci s’accordent, les unités lisibles de chaque côté peuvent être ce que préfère chaque outil, parce qu’on a un chiffre en dessous dont les deux sont dérivés.

Pas partout. Les octets qui comptent le plus sont ceux qui bloquent le premier rendu — le CSS critique, les scripts qui doivent s’exécuter avant que le contenu apparaisse, les polices qui retiennent le texte. Cinquante kilooctets à cet endroit valent mieux que cinq cents dans quelque chose de chargé paresseusement après que la page est utilisable, et un budget qui traite tous les octets comme égaux va optimiser les mauvais avec beaucoup de précision.

C’est aussi là où la question d’unité cesse d’être académique, parce que les budgets de chemin critique sont les plus serrés. Une cible de 150 ko de JavaScript bloquant n’a pratiquement aucune marge ; convertir un chiffre de 0,15 Mio comme s’il faisait 150 ko plutôt que 157,3 ko a consommé cinq pour cent du budget en arithmétique. Sur un morceau chargé paresseusement avec un budget dix fois plus grand, la même erreur est invisible et personne ne devrait y passer du temps.

Un budget est un chiffre qu’une autre personne appliquera des mois plus tard sans le contexte que vous aviez. Cela signifie qu’il a besoin de trois choses énoncées avec lui : la quantité, l’unité avec sa base, et l’étage du pipeline — compressé ou brut, par actif ou par page. L’une des trois laissée implicite sera comblée par hypothèse, et l’hypothèse différera de la vôtre assez souvent pour importer.

La version mécanique consiste à exprimer le budget en octets dans la configuration qui l’applique, et à laisser le chiffre lisible par un humain apparaître dans la documentation à côté. Les octets ne peuvent pas être mal lus, ils se comparent directement à la mesure sous-jacente de tout outil, et ils suppriment le besoin pour quiconque en aval de savoir si la personne qui a fixé le budget entendait 1 000 ou 1 024.

Multiplier par mille et ajouter cinq pour cent. 2,4 Mio font à peu près 2 400 plus 120, donc environ 2 520 ko, contre 2 516,6 exactement. C’est suffisant pour une conversation et pour repérer une erreur d’ordre de grandeur, ce qui est à quoi sert l’arithmétique mentale. Ce n’est pas suffisant pour quoi que ce soit qui sera inscrit dans un fichier de configuration et appliqué.

Le seuil pour le faire sérieusement est de savoir si le chiffre sera comparé à un autre chiffre. Un chiffre cité dans une discussion peut être approximatif ; un chiffre qu’un outil vérifiera, ou qui siégera dans une table à côté d’une mesure venue d’ailleurs, doit être la multiplication exacte, parce qu’un écart de quelques kilooctets dans une comparaison est indiscernable d’une vraie régression. C’est le coût pratique du raccourci : pas un chiffre faux, mais une heure passée à investiguer un changement qui n’a pas eu lieu, et un commit de plus dans l’historique qui n’apporte rien.