Pourquoi votre décodeur a si peu de mémoire

Un téléphone d'entrée de gamme dispose aujourd'hui de plusieurs gigaoctets de mémoire vive. Un décodeur récent en a souvent une fraction, et une bonne partie ne sera jamais disponible pour l'interface. Ce n'est ni de la négligence ni du retard technologique: c'est une conséquence directe du modèle économique, et ça détermine à peu près tout ce qu'on peut écrire comme code dessus.

Le décodeur n'est pas vendu

La différence de fond avec un téléphone est là. Un téléphone est acheté par la personne qui l'utilise, qui compare les fiches techniques et accepte de payer davantage pour un meilleur modèle. Un décodeur est acheté en volume par un opérateur, puis prêté ou loué à l'abonné. Personne ne magasine son décodeur.

L'opérateur en commande des centaines de milliers, parfois des millions. À cette échelle, quelques dollars de composants supplémentaires par boîtier représentent des millions à l'échelle du parc, déboursés immédiatement, alors que le revenu correspondant s'étale sur des années d'abonnement. La décision se prend donc en dollars par unité, pas en confort de développement — et le premier poste qu'on ajuste est la mémoire.

Deuxième contrainte du même ordre: le boîtier restera en service très longtemps. Un opérateur n'échange pas gratuitement plusieurs millions de décodeurs parce que l'interface s'est alourdie. Un matériel déployé aujourd'hui devra faire tourner l'interface de dans huit ans. On ne conçoit donc pas pour le boîtier le plus récent, mais pour le plus modeste encore actif.

Où va la mémoire

Le total annoncé n'a jamais été disponible pour l'application. Il se partage entre plusieurs occupants, dont la plupart ne sont pas négociables.

• Les tampons de décodage vidéo, qui sont volumineux et intouchables: c'est ce qui empêche l'image de figer au moindre irrégularité du réseau.
• Le tampon de composition graphique, dimensionné par la résolution de sortie. Passer de la haute définition à l'ultra haute définition multiplie cette surface par quatre, et cette mémoire-là est consommée en permanence, que l'interface soit riche ou dépouillée.
• Le système, les pilotes, la pile réseau, les services de sécurité et le middleware, qui doivent rester résidents.
• Les métadonnées du guide de programmation, qui grossissent avec le nombre de chaînes et la profondeur d'horaire conservée.

Ce qui reste pour l'interface et les applications tierces est une portion modeste du total, et cette portion est ce que se partagent tous les développeurs qui livrent quelque chose sur la plateforme.

Ce que ça impose au code

La première conséquence est qu'il n'y a pas de dégradation progressive. Sur un ordinateur, une application trop gourmande devient lente. Ici, le système la termine pour récupérer la mémoire, et l'abonné se retrouve brutalement devant la télévision en direct sans explication. Il n'y a pas de zone d'avertissement entre « ça va » et « c'est fini ».

La deuxième est que les images dominent le budget. Une affiche affichée en vignette mais chargée à sa résolution d'origine occupe plusieurs mégaoctets une fois décompressée. Sur un catalogue de quelques centaines de titres, le compte est réglé. Redimensionner côté serveur et libérer ce qui sort de l'écran n'est pas une optimisation tardive, c'est une condition de fonctionnement.

La troisième est que les fuites ne pardonnent pas. Une session de développement dure quelques minutes; une soirée devant la télévision dure des heures. Un écouteur d'événement jamais retiré, qui retient toute une vue après qu'on ait quitté l'écran, ne se voit pas en développement et fait tomber l'application chez l'abonné après quarante minutes. C'est la catégorie de défaut la plus fréquente que j'aie vue en certification.

La contrainte comme information

On peut voir tout ça comme un handicap. Je le vois plutôt comme le retour d'une discipline qu'on a collectivement perdue quand la mémoire est devenue abondante. Sur un décodeur, on sait combien on a le droit de consommer, on le mesure, et on conçoit en conséquence. Ce n'est pas si différent de ce qu'était le développement avant que l'abondance nous permette d'arrêter d'y penser.

Et j'observe que ça déteint. Depuis que je travaille sous ces contraintes, mes applications web sont plus légères, non pas par vertu, mais parce que j'ai pris l'habitude de me demander ce que chaque chose coûte. C'est un réflexe qui se transporte bien.