Pourquoi la taille des programmes est-elle si importante?
Si nous regardons le programme vintage Netscape Navigator ou une ancienne version de Microsoft Word, ces programmes avaient une taille inférieure à 50 Mo. Maintenant, quand j'installe google chrome c'est 200 Mo et la version de bureau de Slack est 300 Mo. J'ai lu une règle selon laquelle les programmes prendront toute la mémoire disponible, peu importe combien, mais pourquoi?
Pourquoi la taille actuelle des programmes est-elle si importante par rapport à il y a 10 ou 15 ans? Les programmes ne font pas beaucoup plus de fonctions et ne sont pas très différents. Qu'est-ce que c'est que le porc de ressources maintenant?
"Regarder très différent" est une question de perception. Les graphismes d'aujourd'hui doivent avoir une belle résolution d'écran totalement différente de ce qu'ils étaient auparavant, avec pour résultat qu'une image de 100 x 100 qui était plus que suffisamment bonne pour un logo aurait maintenant l'air horriblement collante. Il a dû être remplacé par une image 1000x1000 de la même chose, ce qui est un facteur 100 juste là. (Je sais que vous pouvez utiliser des graphiques vectoriels à la place, mais cela ne fait que souligner le point - le code de rendu des graphiques vectoriels a dû être ajouté à des systèmes qui n'en avaient pas besoin auparavant, il ne s'agit donc que d'un compromis entre un type d'augmentation de taille à un autre.)
"Travailler différemment" est également une question de perception. Le navigateur d'aujourd'hui fait massivement plus de choses que celui de 1995. (Essayez de surfer sur Internet avec un ordinateur portable historique un jour de pluie - vous constaterez qu'il est presque inutilisable.) Peu d'entre eux sont très utilisés, et les utilisations n'en connaissent peut-être pas 90%, mais elles sont là.
En plus de cela, bien sûr, la tendance générale à passer moins de temps à optimiser les choses pour l'espace et plus à introduire de nouvelles fonctionnalités. Il s'agit d'un effet secondaire naturel d'ordinateurs plus grands, plus rapides et moins chers pour tout le monde. Oui, il serait possible d'écrire des programmes aussi économes en ressources qu'en 1990, et le résultat serait incroyablement rapide et fluide. Mais ce ne serait plus rentable; votre navigateur prendrait dix ans à compléter, date à laquelle les exigences auraient complètement changé. Les gens avaient l'habitude de programmer avec une extrême attention à l'efficacité parce que les petites machines lentes d'antan les y obligeaient, et tout le monde le faisait aussi. Dès que cela a changé, le goulot d'étranglement pour le succès du programme est passé de pouvoir exécuter du tout à exécuter davantage et des choses plus brillantes , et c'est où nous en sommes maintenant.
Si vous comparez Netscape Navigator à un navigateur moderne, il existe une différence de fonctionnalités énorme . Comparez simplement la spécification HTML 3.2 (51 pages lorsque je fais un aperçu avant impression) avec la spécification HTML actuelle (la version PDF est de 1155 pages). C'est une augmentation de 20 fois la taille.
Netscape Navigator n'avait pas de DOM ni de CSS! Il n'y a pas eu de changements dynamiques du document, pas de JavaScript modifiant le DOM ou les feuilles de style. Aucun onglet. Pas d'audio ni de vidéo. Un navigateur moderne est un programme largement plus complexe.
L'une des raisons est que les données regroupées dans les applications sont plus volumineuses car elles sont de résolution et de qualité supérieures. Une icône à l'époque de Netscape était au maximum de 32x32 pixels, avec au plus 8 bits de profondeur, (peut-être seulement 4), alors que maintenant elle est probablement quelque chose comme 64x64 et elle est en vraie couleur avec transparence, ce qui signifie une profondeur de 32 bits. C'est 16 fois plus grand. Et l'espace est tellement bon marché que les gens ne prennent même pas la peine de vérifier l'option "compressé" lors de la génération d'un PNG.
Une autre raison est que les applications transportent aujourd'hui avec elles une quantité ahurissante de données, ce qui n'était pas le cas pour les applications plus anciennes. Il existe aujourd'hui des applications qui sont livrées avec une présentation "mise en route" en vidéo .
Une autre raison est que les langages de programmation ont tendance aujourd'hui à aller de pair avec des environnements d'exécution riches, qui sont assez grands, à hauteur de 100 Mo chacun. Même si vous n'utilisez pas toutes les fonctionnalités de votre environnement d'exécution, vous devez toujours emballer le tout avec votre application.
Mais la raison principale est qu'il existe aujourd'hui des tonnes et des tonnes de bibliothèques que nous pouvons utiliser dans nos applications, et nous avons développé une culture d'utilisation des bibliothèques afin d'éviter la réinvention constante de la roue. Bien sûr, une fois que vous commencez à utiliser les bibliothèques, plusieurs questions apparaissent et nous avons pris l'habitude de leur donner les réponses les plus libérales:
Vaut-il la peine d'inclure une autre bibliothèque si elle ne sera utilisée que par une seule de mes fonctions? --oui.
Vaut-il la peine d'inclure une autre bibliothèque si je n'ai besoin que d'un petit sous-ensemble de l'ensemble des fonctionnalités offertes par cette bibliothèque? --oui.
Vaut-il la peine d'inclure une autre bibliothèque si son inclusion ne me fera économiser que 2 jours de travail? --oui.
Vaut-il la peine d'inclure plusieurs bibliothèques qui servent plus ou moins le même objectif simplement parce que différents programmeurs sur ma paie sont déjà familiers avec différentes bibliothèques? --oui.
(Veuillez noter que je ne fais qu'observer ces tendances, je ne fais aucune déclaration quant à savoir si je suis d'accord ou en désaccord avec elles.)
Une autre raison mérite d'être mentionnée est qu'en essayant de décider quelle application utiliser parmi plusieurs choix, certains utilisateurs pensent que celle qui occupe plus d'espace sera plus fonctionnelle -emballé, aura des graphismes plus sophistiqués, etc. (Ce qui est complètement absurde, bien sûr.)
Donc, pour conclure, le logiciel se comporte-t-il comme du gaz? A-t-il tendance à occuper tout l'espace dont il dispose? Dans un certain sens, oui, mais pas dans une mesure alarmante. Si nous regardons ce qui prend le plus de place sur nos disques, pour la plupart d'entre nous, la réponse est que ce ne sont pas des applications, mais des médias tels que les films et la musique de loin . Le logiciel n'a pas gonflé au même rythme que la capacité de stockage a augmenté, et il est peu probable qu'il le soit jamais, donc à l'avenir, les applications représenteront probablement une fraction négligeable de l'espace de stockage disponible pour les utilisateurs.
En plus des autres ansers, il y a 10 ans, il y avait généralement des versions distinctes pour les versions localisées/internationalisées. Maintenant, c'est généralement le cas que les programmes intègrent la prise en charge complète de la localisation dans chaque version publiée, ce qui réduit la taille du programme.
Une des raisons est les dépendances. Un programme avec des fonctionnalités riches et une belle apparence nécessite beaucoup de choses - cryptage, vérification orthographique, travail avec XML et JSON, édition de texte et beaucoup d'autres choses. D'où viendraient-ils? Vous pouvez peut-être rouler les vôtres et les garder aussi petits que possible. Vous utilisez probablement des composants tiers (open source sous licence MIT peut-être) qui ont beaucoup de fonctionnalités dont vous n'avez jamais réellement besoin, mais une fois que vous avez besoin d'une seule fonction d'un composant tiers, vous devez souvent transporter tout le composant. Donc, vous ajoutez de plus en plus de dépendances et au fur et à mesure qu'elles évoluent et que votre programme grandit, cela dépend également d'eux.
Bien que les graphiques/l'utilisabilité soient en effet des facteurs contributifs, il y en a énormément qui sont de la bibliothèque/du code compilé en excès.
Exemple de la petite taille du code: MenuetOS, un système d'exploitation complet 64 bits avec des applications puissantes qui tient sur une seule disquette.
Exemple de la taille d'un code sans raison évidente: j'ai fait une simple sortie de texte "Bonjour tout le monde!" à Ada récemment. L'exécutable compilé dépassait 1 Mio !. Le même exécutable dans Assembly est juste un Kio ou 2 (et la majeure partie de cela est une surcharge exécutable, le code en cours d'exécution est de dizaines d'octets).
Il est trivialement vrai que le logiciel doit être construit pour s'adapter à deux choses: les utilisateurs et le matériel disponible. Un programme est adapté à son objectif s'il fait ce que l'utilisateur veut en temps opportun avec le matériel à sa disposition. Eh bien duh. Mais au fur et à mesure que le matériel s'améliore dans pratiquement toutes les dimensions mesurables, le nombre de programmes discrets qui passent d'inadaptés à ajustés augmente - l'espace de conception s'agrandit:
- Langages de niveau supérieur permet d'exprimer des idées en moins de code et de temps qu'auparavant. Cette complexité réduite, à l'inverse, permet d'exprimer des idées de plus en plus complexes.
- Bundling plus de données avec l'application peuvent le rendre instantanément plus utilisable. Par exemple, il ne faudra probablement pas longtemps avant que les applications de vérification orthographique soient livrées avec toutes les langues connues de l'humanité - ce n'est que quelques gigaoctets, après tout.
- compromis matériels donne aux développeurs et aux utilisateurs plus de choix dans la ressource qui leur tient à cœur. Voir par exemple FLAC/OGG vs WAV, SVG vs PNG, index de base de données.
- Interfaces humaines échange souvent ce qui équivaudrait auparavant à d'énormes quantités de matériel pour la convivialité. L'anticrénelage, les résolutions élevées, le rafraîchissement rapide et le glissement entre ce qui équivaut à des panneaux discrets, tout cela permet une expérience plus réaliste, et donc intuitive et comparable.
C'est certainement vrai pour les applications Android. Il y a quatre ans, une application simple prenait environ 2 à 5 mégaoctets. De nos jours, une application simple prend environ 10 à 20 mégaoctets.
Plus il y a d'espace disponible, plus la taille de l'application est grande.
Je pense qu'il y a deux raisons principales en cas d'Android:
Google a étendu le Android framework, a ajouté beaucoup de nouvelles fonctionnalités.
Les développeurs ne s'en soucient plus. Les images sont incluses dans une résolution beaucoup plus élevée (bien sûr, les résolutions d'écran du smartphone ont augmenté), les bibliothèques tierces sont incluses sans réfléchir.
Cela se résume en grande partie au temps du développeur et au coût de ce temps. À l'époque où Visual Basic est arrivé sur la scène, il était en concurrence avec C/C++ et le gros problème était que vous pouviez écrire `` Hello World '' en ANSI C pour Windows en peut-être 15K. Le problème avec VB était que vous aviez toujours l'albatros de la bibliothèque d'exécution 300K.
Maintenant, vous pourriez 10x la taille de votre programme VB et ce serait encore juste quelques K de plus, mais 10x la taille de votre programme C/C++ et vous regardez quelques MOIS plus de développement.
En fin de compte, le fardeau de vos applications est un petit prix à payer pour les énormes sauts dans la production de développement, la réduction des prix et l'immensité des capacités qui n'auraient jamais été possibles dans les anciens jours de développement artisanal; lorsque les programmes étaient petits et rapides mais aussi faibles, incompatibles entre eux, insuffisamment présentés et coûteux à développer.
Avec le temps, les besoins des utilisateurs évoluent et sont de plus en plus exigeants, de sorte que les fournisseurs/auteurs de différents logiciels sont obligés de satisfaire ces besoins au nom de la concurrence.
Mais satisfaire un nouveau besoin signifie souvent ajouter un nouveau code. Un nouveau code signifie de nouvelles vulnérabilités à corriger. La correction de nouvelles vulnérabilités peut ajouter du code ou ouvrir des portes à de nouvelles vulnérabilités.
Chaque fonctionnalité ajoutée pour satisfaire les besoins d'un utilisateur peut nécessiter plus de puissance processeur pour la vitesse (nous nous plaignons tous de la vitesse de tel ou tel navigateur), de nouvelles ressources graphiques pour de meilleurs effets visuels ... etc.
Tout cela signifie ajouter de nouvelles couches d'applications (code), de sécurité et parfois de matériel.
Une grande partie de la taille provient de bibliothèques intégrées. De nos jours, de nombreuses applications sont construites à l'aide d'électrons qui regroupent une énorme quantité avec l'application. Si vous installez des applications sous Linux, elles sont généralement beaucoup plus petites car une grande partie de l'application est déjà installée via des bibliothèques partagées que d'autres programmes utilisent également.