Pourquoi la taille des programmes est-elle si grande?


186

Si nous regardons le programme vintage Netscape Navigator ou une version antérieure de Microsoft Word, ces programmes mesuraient moins de 50 Mo. Maintenant, lorsque j'installe Google Chrome, il s'agit de 200 Mo et la version de bureau de Slack, de 300 Mo. J'ai lu certaines règles qui stipulent que les programmes utiliseront toute la mémoire disponible, peu importe la quantité 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 semblent pas très différents. Qu'est-ce que c'est que la ressource porc maintenant?


134
Seulement 4 fois la taille?! C'est étonnant, compte tenu du nombre de navigateurs modernes
Richard Tingle

23
En note de bas de page, je pense que "certaines règles prévoient que les programmes utiliseront toute la mémoire disponible, peu importe la quantité utilisée mais pourquoi?" fait probablement référence à la mémoire à accès aléatoire plutôt qu’à l’espace disque physique, du moins ce serait mon interprétation de celle-ci. Pourrait être faux.
Trotski94

103
Ce que vous dites, c’est qu’un programme qui utilisait jadis 10 dollars d’espace disque dur occupe maintenant environ 30 cents d’espace disque? J'ai du mal à m'inquiéter.
Eric Lippert le

49
«Les programmes ne font pas beaucoup plus de fonctions» - bon seigneur. Jetez simplement un coup d'œil aux spécifications HTML 4 et CSS 1 (ne vous inquiétez pas, je vais attendre, cela ne vous prendra pas longtemps, même si vous les lisez). Netscape 4 n'a même pas réussi à les implémenter correctement. La quantité de HTML et de CSS nouveaux et fous que Chrome prend en charge est considérable. De plus, il a des onglets. Et se met à jour toutes les six semaines.
Paul D. Waite

13
BTW. 50 Mo dans Netscape était un peu volumineux, mais pour l’instant, cela incluait non seulement un navigateur Web, mais aussi un client de messagerie et un éditeur HTML, et peut-être même autre chose.
el.pescado

Réponses:


266

"Avoir une apparence très différente" est une question de perception. Les graphismes actuels doivent bien paraître à des résolutions d'écran totalement différentes de ce qu'ils étaient, avec pour résultat qu'une image 100x100 qui suffisait amplement à un logo paraissait maintenant terriblement collante. Il a fallu la remplacer par une image 1000x1000 de la même chose, soit un facteur de 100 ici. (Je sais que vous pouvez utiliser des graphiques vectoriels à la place, mais cela ne fait que souligner le fait que du code de rendu graphique vectoriel a dû être ajouté à des systèmes qui n'en avaient pas besoin auparavant. Il s'agit donc simplement d'un compromis entre un type d'augmentation de taille à un autre.)

"Travailler différemment" est également une question de perception. Le navigateur actuel en fait énormément plus qu'en 1995. (Essayez de surfer sur Internet avec un ordinateur portable historique un jour de pluie - vous verrez qu'il est presque inutilisable.) Peu d'entre eux sont très utilisés et leurs utilisations peuvent être complètement ignorantes. % d'entre eux, mais ils sont là.

À cela s’ajoute bien entendu la tendance générale à consacrer moins de temps à l’optimisation de l’espace et davantage à l’introduction de nouvelles fonctionnalités. Ceci est un effet secondaire naturel des ordinateurs plus grands, plus rapides et moins chers pour tout le monde. Oui, il serait possible d'écrire des programmes utilisant autant de ressources que d'habitude en 1990 et le résultat serait incroyablement rapide et fluide. Mais ce ne serait plus rentable; votre navigateur prendrait dix ans, mais les exigences auraient complètement changé. Les gens programmaient avec une extrême attention à l'efficacité parce que les machines lentes et petites d'antan l'ont forcé à le faire, et que 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 fonctionner du tout à l'exécutionde plus en plus de choses brillantes , et voilà où nous en sommes maintenant.


120
Les exemples concrets qu'un navigateur moderne devrait inclure sont les bibliothèques de chiffrement, la base de données Unicode, un runtime JavaScript et l'optimisation du compilateur JIT, des codecs vidéo, un rendu PDF, ainsi qu'un moteur de rendu compliqué et des analyseurs syntaxiques pour tous les types MIME pris en charge. Cela s’ajoute bien, mais contrairement aux jeux, les navigateurs n’exigent pas beaucoup d’actifs de haute résolution. Un téléchargement moderne de Firefox ne pèse que 40 à 50 Mo compressés.
amon

23
"le résultat serait incroyablement rapide et lisse" - cela ressemble à un voeu pieux.
Doc Brown

16
@amon N'oubliez pas que les navigateurs incluent également d'autres types de ressources et une API complète pour les plugins et autres. Ils viennent même avec des outils de débogage (profileurs, analyseurs de réseau, inspecteurs d’éléments, une console entièrement fonctionnelle, des débogueurs et bien d’autres encore). Les navigateurs se rapprochent d'un système d'exploitation complet que nous ne pouvons tous l'imaginer. Il y a même une discussion en cours sur l'utilisation de Web Assembly! Le PO devrait être surpris par la quantité de merde qu’il peut accumuler dans un navigateur.
Ismael Miguel

10
@IsmaelMiguel En ce qui concerne Chrome OS est, les navigateurs déjà sont un système d'exploitation complet. ;-P
Ajedi32

111
tendency to spend less time on optimizing things for space Cette. Lorsque j'écris du code, je n'optimise ni l'espace ni la vitesse. J'optimise pour la maintenance. Il est plus important que la base de code puisse changer facilement que d'être rapide ou petit. Je peux m'attendre à ce que pour chaque réclamation relative à la vitesse du programme, j'obtienne dix demandes de nouvelles fonctionnalités et aucune demande pour la réduire.
user2023861

109

Si vous comparez Netscape Navigator à un navigateur moderne, il y a une énorme différence de fonctionnalité. Il suffit de comparer 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 fait 1155 pages). C'est 20 fois plus grand.

Netscape Navigator n'avait pas de DOM ni de CSS! Il n'y a eu aucune modification dynamique du document, aucun code JavaScript ne modifiant le DOM ou les feuilles de style. Aucun onglet. Pas d'audio ou de vidéo. Un navigateur moderne est un programme beaucoup plus complexe.


12
Oui, les navigateurs récents font des animations, des dégradés, des effets de filtres d'image, JavaScript, des graphiques 2D (canevas), des graphiques 3D avec WebGL, la génération audio, une manette de jeu (!), Le décodage vidéo, le stockage avancé côté client, la communication d'égal à égal (WebRTC), géolocalisation, WebSocket, WebCryptography, MIDI, accès au micro / webcam, notifications, etc.
ysdx

1
Ajoutez encore plus de choses (DOM, CSS, Javascript) à plus de biens immobiliers (moniteurs multiples, augmentation massive de la résolution: les écrans d'ordinateur se grossissent: de 1999 à 2011 ) - 800x600 vs 1920x1080 vs 4k ... 8k et au-delà ... 1080 à 4k est quadruple la résolution ... 8k est quadruple à nouveau.
WernerCD

7
@WernerCD Le simple fait d'avoir un écran plus grand ne nécessite pas de plus gros fichier binaire. Une icône 32 bits de 64 sur 64 pixels requiert la même quantité d’espace sur le disque, qu’elle soit affichée sur un moniteur 800x600 ou 2560x1440. Redimensionner votre fenêtre ne change pas la taille du binaire. Ce qui compte dans les écrans, c'est lorsque vous commencez à faire des choses comme le doublage de pixels, alors vous avez besoin de ressources plus importantes pour continuer à avoir une apparence nette.
8bittree

1
@ 8bittree, les performances du logiciel peuvent être plus sollicitées. Et un code plus performant peut être plus complexe (par exemple, un site Web utilisant Canvas nécessite probablement plus de complexité et de code que celui utilisant des SVG). Mais oui, vous avez généralement raison.
Paul Draper

1
S'il est certainement vrai que le HTML actuel en fait beaucoup plus que le HTML 3.2, la spécification elle-même est aussi beaucoup plus détaillée, ce qui ajoute une quantité importante de contenu à la spécification. Comparez la longueur de la description de l' EMélément HTML 3.2 - huit ou neuf mots - avec la longueur de celle-ci dans la spécification HTML 5 - plus qu'un écran comprenant les éléments environnants décrivant l'élément, où il est applicable et quelle est son utilisation prévue.
un CVn

79

Une des raisons est que les données contenues dans les applications sont plus volumineuses, car leur résolution et leur qualité sont optimales. À l'époque de Netscape, une icône ne dépassait pas 32 x 32 pixels, avec une profondeur maximale de 8 bits (peut-être seulement 4), alors qu'elle est probablement de l'ordre de 64x64 et qu'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 si bon marché que souvent les gens ne se donnent même pas la peine de cocher l’option «compressé» lors de la génération d’un fichier PNG.

Une autre raison est que les applications contiennent actuellement une quantité de données ahurissante, contrairement aux applications plus anciennes. Il existe aujourd'hui des applications livrées avec une présentation vidéo "pour commencer" .

Une autre raison est que les langages de programmation actuels ont tendance à aller de pair avec des environnements d'exécution riches, assez volumineux, pouvant atteindre 100 Mo chacun. Même si vous n'utilisez pas toutes les fonctionnalités de votre environnement d'exécution, vous devez quand même regrouper le tout dans votre application.

Mais la raison principale en est qu’aujourd’hui, il existe des tonnes et des tonnes de bibliothèques que nous pouvons utiliser dans nos applications, et nous avons développé une culture de l’utilisation des bibliothèques afin d’éviter la réinvention constante de la roue. Bien sûr, lorsque vous commencez à utiliser les bibliothèques, plusieurs questions se posent 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 n’est utilisée que par une de mes fonctions? - oui

  • Vaut-il la peine d'inclure encore une autre bibliothèque si je n'ai besoin que d'un petit sous-ensemble de toute la richesse des fonctionnalités offertes par cette bibliothèque? - oui

  • Vaut-il la peine d'inclure encore une autre bibliothèque si son inclusion ne me sauve que de deux 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 de ma liste de paie sont déjà familiarisés avec différentes bibliothèques? - oui

    (Veuillez noter que je ne fais qu'observer ces tendances, je ne déclare absolument pas si je suis d'accord ou non avec elles.)

Une autre raison à noter est que, pour tenter de choisir l’application à utiliser parmi plusieurs choix, certains utilisateurs pensent que celle qui occupe plus d’espace sera plus riche en fonctionnalités, aura des graphismes plus sophistiqués, etc. (Ce qui est totalement absurde .)

Donc, pour conclure, les logiciels se comportent-ils comme du gaz? At-il tendance à occuper tout l’espace disponible? Dans un certain sens, oui, mais pas dans une mesure alarmante. Si nous regardons ce qui se passe le plus de place sur nos disques, pour la plupart d' entre nous , la réponse est qu'il n'y a pas des applications, mais les médias tels que les films et la musique de loin . Les logiciels n'ont pas gonflé au même rythme que la capacité de stockage, et il est peu probable que cela se produise jamais. Par conséquent, les applications représenteront probablement une fraction négligeable de l'espace de stockage disponible pour les utilisateurs.


17
C'est la bonne réponse. Les commentaires (actuellement) les mieux notés mentionnent davantage de fonctionnalités, mais cela n'explique pas entièrement la taille accrue. La taille provient des bibliothèques incluses qui fournissent ces fonctionnalités.
user1936

5
@IsmaelMiguel eh bien, je parlais des utilisateurs réguliers. En outre, les jeux constituent un cas particulier, car ces 35 Go sont principalement des médias, pas de code, ni des bibliothèques. Il se trouve que ce sont des médias que vous ne pouvez visionner que via une application spéciale, le jeu. Mais même pour un joueur, 35 Go ne sont rien sur les lecteurs multi-téraoctets d'aujourd'hui. Quoi qu'il en soit, supposons que si vous êtes un joueur qui tient à posséder un petit lecteur, vous n'êtes en aucun cas un représentant des utilisateurs.
Mike Nakis le

2
@MikeNakis Tous les joueurs ne disposent pas d'un lecteur de 1 To, ni de l'argent nécessaire pour acheter un disque SSD de 256 Go. Certains, comme moi, ont un SSD de 128 Go ou un ordinateur portable de moins de 500 Go. Il y a quelque temps, 80% de mon utilisation de l'espace SSD était simplement des jeux. C'était simplement 3-4 jeux, en mangeant l'espace. Et dans le jeu lui-même, presque tout le monde a un ordinateur portable et y joue.
Ismael Miguel

5
@ Mike oh, ce n'est pas grave. Lorsque nous parlons de la taille d'une application, nous entendons soit la taille du fichier d'installation téléchargeable, soit l'espace total occupé par l'application sur le disque une fois installé. Cela inclut les bibliothèques, les médias, les données, tout. Et pour éviter les problèmes d’incompatibilité, les applications sont généralement livrées avec la plupart des bibliothèques dont elles ont besoin, au lieu d’espérer que les bibliothèques seront déjà installées et qu’elles auront la bonne version, etc. La taille du fichier exécutable principal pas vraiment d'aucun intérêt, ni d'aucune conséquence.
Mike Nakis

3
@IsmaelMiguel Pour un programmeur, ce sont probablement leurs différentes machines virtuelles, leurs conteneurs de menu fixe, etc. Il n'y a pas de meilleur gonflement que de multiplier des systèmes ballonnés ;-)
cmaster

16

En plus des autres pays, il y a 10 ans, il existait généralement des versions séparées pour les versions localisées / internationalisées. Désormais, les programmes vont généralement intégrer une prise en charge complète de la localisation dans chaque version publiée, ce qui correspond à la taille du programme.


5
Je me trompe peut-être, mais je travaille dans l'illusion que les cordes sont la moindre partie de ce problème. Certes, il existe de nombreuses langues, mais le nombre de chaînes qu'un utilisateur voit est toujours très limité. Après tout, l’un des moyens les plus sûrs d’échouer sur votre interface utilisateur est d’inclure trop de texte.
cmaster

5
En ajoutant à ce que @cmaster a dit, Firefox ne propose pas spécifiquement la localisation complète (et pendant que j'y réfléchis, OpenOffice non plus.)
BenjiWiebe

2
@cmaster Strings, no. Mais la vidéo et l'audio localisés, en particulier dans le contexte des jeux? Dans le jeu IIRC, il existait un jeu de 60 Go (GTA V?) Dans lequel> 10 Go étaient uniquement de l’audio localisé. C'est un morceau important.
Bob le

@Bob Bien, je ne pensais pas aux jeux, ils semblent être la seule grande exception à ce que j'ai écrit.
cmaster

Pour chaque langue, la table des chaînes peut ajouter quelques Ko supplémentaires. Seules les icônes des applications à elles seules
dépassent

13

Une des raisons est les dépendances. Un programme riche en fonctionnalités et en apparence a besoin de beaucoup de choses - cryptage, vérification orthographique, utilisation de XML et JSON, édition de texte, etc. D'où viendraient-ils? Peut-être que vous roulez les vôtres et que vous les gardez aussi petits que possible. Très probablement, vous utilisez des composants tiers (Open Source sous licence MIT, par exemple) qui possèdent de nombreuses fonctionnalités dont vous n’avez jamais besoin, mais lorsque vous avez besoin d’une seule fonction à partir d’un composant tiers, vous devez souvent transporter l’ensemble du composant. Vous ajoutez donc de plus en plus de dépendances et au fur et à mesure qu’elles évoluent et grandissent, votre programme qui en dépend grandit également.


Je suis un peu curieux de savoir pourquoi cela a eu deux votes négatifs la nuit.
Sharptooth

6
Je ne l'ai pas fait mais je ne pense pas que cela réponde vraiment à la question de manière suffisamment approfondie. Cela dit à peu près tout simplement "le logiciel grossit parce qu'il fait plus de choses", et vous verrez d'après les autres réponses qu'il y a vraiment plus que cela.
Courses de légèreté en orbite

1
Un facteur lié est que, dans les systèmes qui utilisent des liaisons statiques, un éditeur de liens n'a besoin que de récupérer le code réellement utilisé [certains éditeurs de liens capturent toujours tout, mais les meilleurs essaient d'être sélectifs]. Lorsque vous utilisez une liaison dynamique, en particulier si les modules peuvent être partagés, même si le premier code qui installe un module n’a besoin que d’une fonction, il n’ya aucun moyen de savoir quelles fonctions peuvent être nécessaires à d’autres codes souhaitant partager le module.
Supercat

@sharptooth je ne me demande même plus. Bien que, dans la plupart des cas, le système fonctionne, je constate également que des réponses brisées, terriblement fausses, sont votées comme des fous et acceptées, tandis que les bonnes réponses sont trop souvent rejetées dans l'oubli ...
Brian Knoblauch

10

Bien que les graphiques / la convivialité soient effectivement des facteurs contributifs, il y en a énormément qui est du code compilé par bibliothèque / excès.

Exemple de faible consommation de code: MenuetOS, un système d’exploitation 64 bits complet doté d’applications puissantes et pouvant être inséré sur une seule disquette.

Exemple de grosseur de code sans raison évidente: j’ai créé une simple sortie de texte "Hello, World!" à Ada récemment. L'exécutable compilé était supérieur à 1 MiB !. Le même exécutable dans l’assemblage est juste un KiB ou 2 (et la majeure partie de cela est une surcharge exécutable, le code en cours d’exécution est composé de dizaines d’octets).


3
Qu'est-ce qu'une disquette? ;)
500 - Erreur serveur interne

@ 500-InternalServerError Qu'est-ce que Ada? : D
BenjiWiebe

3
pour les nouveaux arrivants, la disquette coûte environ 1,4 Mo
Sarge Borsch le

3
J'ai vu des exécutables Ada modernes sous 200 octets. Mais si votre compilateur tire des choses comme une exécution complète de tâches par défaut, que vous utilisiez des tâches ou non, alors il faut s’attendre à 1 Mo environ. Et cela ne vaut généralement pas la peine de la dépouiller.
Brian Drummond le

@BrianDrummond, sonne comme un runtime vraiment merdique, ou un runtime merdique et une bibliothèque et un éditeur de liens. Dans une vidéo de formation que j'ai visionnée il y a de nombreuses années, Jean Ichbiah et ses collaborateurs ont indiqué qu'une exécution typique d'Ada (pour la version originale du langage) serait d'environ 4K. Par curiosité, j'ai vérifié cela par rapport au package d'exécution TI 320C30 que nous utilisions. Il avait raison sur l'argent.
John R. Strohm

7

Il est trivialement vrai que le logiciel doit être conçu de manière à s’adapter à deux choses: les utilisateurs et le matériel disponible. Un programme est adapté à son objectif s'il fait ce que l'utilisateur souhaite en temps voulu avec le matériel à sa disposition. Bien duh. Mais au fur et à mesure que le matériel informatique améliore sensiblement toutes les dimensions mesurables, le nombre de programmes discrets qui évoluent d'inaptitude à adaptation augmente: l'espace de conception s'agrandit:

  • Les langages de niveau supérieur permettent d’exprimer des idées en moins de code et de temps qu’auparavant. Inversement, cette complexité réduite permet d’exprimer des idées de plus en plus complexes.
  • Regrouper plus de données avec l'application peut le rendre instantanément plus utilisable. Par exemple, il ne faudra probablement pas longtemps avant que les applications de vérification orthographique arrivent avec toutes les langues connues de l’humanité - ce n’est que quelques gigaoctets, après tout.
  • Les compromis matériels permettent aux développeurs et aux utilisateurs d'avoir plus de choix quant aux ressources qui les intéressent. Voir par exemple FLAC / OGG vs WAV, SVG vs PNG, index de base de données.
  • Les interfaces humaines échangent souvent ce qui était auparavant une énorme quantité de matériel en termes de convivialité. L'anti-aliasing, les résolutions élevées, le rafraîchissement rapide et le glissement entre des panneaux discrets permettent une expérience plus réaliste, et donc intuitive et relatable.

6

Ceci 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 l'espace disponible est grand, plus la taille de l'application est grande.

Je pense qu'il y a deux raisons principales dans le cas d'Android:

  • Google a étendu le cadre Android et ajouté de nombreuses 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 été augmentées), les bibliothèques tierces sont incluses sans réfléchir.


1
Ce dernier point est tout à fait exact.
Courses de légèreté en orbite

3
J'ai créé un total d'une application Android et l'APK est de 0,05 Mo. Là encore, cela ne fait pas beaucoup. Je me demande encore pourquoi une application chronomètre (avec une quantité de fonctionnalités similaire à la mienne, bien que complètement différente) nécessite plusieurs Mo.
Immibis

5
Le dernier point est erroné, les développeurs font des soins. Nous devons juste jongler avec diverses priorités et rendre cette application un peu plus grande est logique.
NPSF3000

Cela n'a également pas aidé que le SDK (à l'époque) ait insisté pour ajouter une bibliothèque de 5 + MB à mon application de 0,05 Mo dont je n'avais pas besoin, et je devais me souvenir de la supprimer avant la construction de la version.
Immibis

4

Cela dépend en grande partie du temps passé par le développeur et de son coût. À l'époque où Visual Basic est arrivé pour la première fois sur le marché, il était en concurrence avec C / C ++ et le gros problème était que vous pouviez écrire «Hello World» dans ANSI C pour Windows à environ 15K. Le problème avec VB était que vous aviez toujours l'albatros de la bibliothèque d'exécution 300K.

Désormais, vous pourriez multiplier par 10 la taille de votre programme VB, mais ce ne serait encore que quelques K de plus, mais 10 fois la taille de votre programme C / C ++ et vous envisagez un développement de quelques mois.

En fin de compte, le fardeau de vos applications est un faible prix à payer pour les énormes sauts dans la production de développement, la réduction du prix et l’immensité des capacités qui n’auraient jamais été possibles dans les vieux jours de développement conçus à la main; quand les programmes étaient petits et rapides mais aussi faibles, incompatibles les uns avec les autres, sous-développés et coûteux à développer.


2
Cet article est plutôt difficile à lire (mur de texte). Pourriez - vous l' esprit modifier ing dans une meilleure forme?
moucher

1
"10 fois la taille" de Hello World nécessite "plusieurs mois de développement"? Se brosser les dents dix fois implique-t-il de se tenir devant un miroir sans arrêt pendant un mois?
bcrist

Le brossage des dents x fois est une fonction linéaire de x, mais la programmation n’est généralement pas une fonction linéaire. Si vous fabriquez chaque ligne de code en utilisant les fonctions de langage les plus simples, vous obtenez un code rapide et petit, mais à un coût plus élevé par niveau de complexité. Les langages de niveau supérieur sont plus lourds mais gardent le coût plus proche d’une fonction linéaire de la complexité.
Andyb

2

Au fil du temps, les besoins des utilisateurs évoluent et sont de plus en plus exigeants. Les éditeurs / auteurs de différents logiciels sont donc obligés de satisfaire ces besoins au nom de la concurrence.

Mais satisfaire un nouveau besoin signifie souvent ajouter un nouveau code. Nouveau code signifie 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 de processeur pour plus de rapidité (nous nous plaignons tous de la vitesse de tel ou tel navigateur), de nouvelles ressources graphiques pour de meilleurs effets visuels ... etc.

Tout cela implique l'ajout de nouvelles couches d'applications (code), de sécurité et parfois de matériel.


0

Une grande partie de la taille provient de bibliothèques intégrées. De nos jours, de nombreuses applications sont construites à l'aide d'électron, qui regroupe énormément d'applications. Si vous installez des applications sur 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.


-1

Lors de la construction du logiciel, si vous avez besoin de la fonction A, vous importerez un module A *. A * peut résoudre A, mais A * peut résoudre des problèmes plus que A, et A * peut être volumineux. Tous les grands modules donnent lieu à un logiciel de grande taille.

Peut-être pas la même chose, mais quelque chose comme ceci: Si vous avez juste besoin d’imprimer "hello world" sur une console en utilisant Java, vous devez avoir installé JRE (> 60 Mo).

Si l'exemple de Java n'est pas bon, essayez celui-ci: si le logiciel doit se connecter à un fichier, il peut utiliser un module de journalisation qui peut réellement créer des journaux sur une base de données, sur le réseau et sur d'autres fonctionnalités, mais ces fonctions ne sont jamais utilisées le projet.


Pourquoi exactement il y a 5 votes négatifs et pas un seul commentaire pour expliquer pourquoi?
Kromster

1
@KromStern La première section passe en revue le fonctionnement des bibliothèques et le fait de manière très floue avec une utilisation incohérente de code. Je soutiens que cela ne répond pas vraiment à la question. La deuxième section utilise Java comme exemple (bien qu’essayer de prétendre que le JRE devrait être considéré comme faisant partie de la croissance de la taille de l’application - ce qui manque encore l’objet de la question et qui n’est pas un exemple juste et continue à perpétuer la malentendus de Java). Dans l’ensemble, c’est soit faux, soit répète des points dans des réponses précédentes, mieux rédigées.

1
Votre exemple de connexion au réseau ou à un fichier n’est pas bon non plus, car du point de vue du code, les deux sont des fichiers et sont gérés exactement de la même manière (la distinction entre fichier et réseau est gérée par le système d’exploitation). Je n'ai pas encore vu de structure de journalisation qui inclut "se connecter à la base de données" dans le cadre de ses fonctionnalités principales, car cela serait compliqué par les pilotes Oracle vs MySQL vs SQL Server vs Postgres vs ... et les différences dialectiques.

@ user40980 La distinction entre le fichier et le réseau n'est pas gérée par le système d'exploitation. Ils ont besoin d'appels au système d'exploitation différents pour se connecter et écrire. L'accès à la base de données est géré via une couche d'indépendance de la base de données telle que JDBC ou libdbi. (Ce qui à son tour peut attirer des pilotes pour toutes les différentes bases de données supportées!)
immibis

-2

J'ai lu certaines règles qui stipulent que les programmes utiliseront toute la mémoire disponible, peu importe la quantité mais pourquoi?

Ce n'est pas tout à fait vrai. Les systèmes ne libèrent pas la mémoire qu'ils ont utilisée tant que le système d'exploitation n'est pas soumis à une pression mémoire. C'est une amélioration de la performance. Si vous parcouriez une page contenant des images, vous vous éloignez. Vous pouvez revenir en arrière et avoir à nouveau besoin de l'image. Si le système d'exploitation dispose de la mémoire RAM, inutile de l'effacer tant que vous n'êtes pas certain de ne plus en avoir besoin.

Si vous effacez immédiatement la mémoire, les cycles de la CPU et la bande passante de la mémoire seraient éloignés de la mémoire de l'utilisateur, qui souhaitera probablement que des pages Web très réactives soient affichées à l'écran.

Le système d'exploitation consomme toute la mémoire non disponible, dont la majorité est destinée au cache du système de fichiers.

La gestion de la mémoire est un problème difficile à résoudre, mais des personnes très intelligentes y travaillent tout le temps. Rien n'est délibérément gaspillé et l'objectif principal est de vous fournir un ordinateur très réactif.


3
Ce n'est pas du tout ce dont il est question. La mémoire virtuelle et le ramassage des ordures venaient d'être inventés lorsque cette citation avait été écrite, et ils n'étaient pas répandus.
Jörg W Mittag le

-2

Il se peut que les programmes tendent à s’étendre pour occuper l’espace disponible, à l’instar du phénomène de banlieue qui consiste à ajouter de nouvelles voies à une autoroute encombrée et à rétablir l’encombrement du trafic en quelques années.

Mais si vous examinez la situation, vous constaterez peut-être que leurs programmes font plus de choses. Les navigateurs, par exemple, exécutent des graphismes plus sophistiqués, ont des outils de développement sophistiqués qui n'existaient pas il y a quelques années, etc. Ils se connectent également à de nombreuses bibliothèques, n'utilisant parfois qu'une petite partie du code. Ainsi, bien que la taille des programmes puisse augmenter pour remplir la mémoire disponible, cela peut être dû à des raisons légitimes.


2
cela ne semble rien offrir de substantiel sur les points évoqués et expliqués dans les 13 réponses précédentes
gnat

-3

Les bibliothèques construites sur des objets qui ne sont pas optimisés nécessitent plus de mémoire pour charger, installer et davantage de cycles de calcul. Le code objet est pour la plupart gonflant.

Parcourez simplement le code C ++ standard en cours d'exécution pour afficher tous les appels d'objet assert () ed afin de vous assurer qu'ils sont des objets valides. Lorsque vous concevez couche après couche des objets encapsulant, les sous-couches sont gonflées et opaques. Les programmeurs deviennent paresseux et prennent plus d'objets parce que c'est plus rapide que de redéfinir ce qui se limite aux fonctionnalités nécessaires. C'est vraiment aussi simple que cela.

Considérez la taille du noyau Linux C, uniquement le noyau, par rapport à la taille des applications personnalisées. Le noyau peut exécuter la machine entière. Mais il n'a pas été construit aussi rapidement que les applications, il faut du temps pour créer les meilleures fonctionnalités.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.