Gonflement des logiciels en termes de ressources processeur - pourquoi les nouvelles versions de l'application sont-elles parfois beaucoup plus lentes que les anciennes?

Prélude

C'était un jeudi soir ordinaire. Je suis rentré du travail, je me suis assis devant l'ordinateur portable, je l'ai allumé, j'ai démarré Skype et j'ai commencé à attendre qu'il démarre enfin complètement et complètement. Et puis j'ai soudain pensé - pourquoi cela a-t-il pris si longtemps à charger, et même le système est clairement difficile à supporter ce processus?

J'ai décidé d'examiner le gestionnaire de tâches pour estimer la quantité de ressources consommées par Skype en arrière-plan. Mais d'abord, un peu de calculs préliminaires. Et combien cela devrait-il consommer des ressources? Je parle du fond maintenant. Ceux. lorsqu'il n'y a pas de connexion vidéo, je ne parle même au microphone avec personne. Tout ce qui est est une liste de contacts, qui s'affiche sous forme d'icônes et de noms, et un menu dans lequel vous pouvez choisir quelque chose.

Ceux. il s'agit en fait d'une forme à partir de laquelle vous pouvez lancer des menus supplémentaires. Il y a une liste sur ce formulaire. Et une zone de texte pour saisir des messages à quelqu'un, quelques boutons. Il y a une quinzaine d'années, lorsque j'écrivais en Delphi, une telle application (avec un seul formulaire) pesait quelques centaines de kilo-octets. Bien sûr, depuis lors, l'environnement de développement a commencé à consommer beaucoup plus de ressources, les composants visuels sont devenus plus riches. Cependant, même avec cette progression, Skype en arrière-plan devrait peser autour de 10 mégaoctets maximum. Après tout, je ne parle à personne ni n’appelle personne, que puis-je y dépenser autant?

Vous pouvez regarder cette question et, d'autre part, comme disent les mathématiciens, l'équivalence. Sans appels vidéo et conversations au microphone, Skype offre la possibilité de voir lequel des interlocuteurs est actuellement sur le réseau, ainsi que de lui envoyer un message texte, enfin, et de recevoir un message texte en réponse de quelqu'un. Ceux. c'est essentiellement ICQ - donc, bien, probablement en arrière-plan, très probablement, Skype devrait-il prendre autant que ICQ en mémoire? Vérifions maintenant en pratique ces calculs. Nous regardons la consommation de mémoire dans le TaskManager:



Skype occupe-t-il 158 Mo de mémoire? Êtes-vous sérieux considérant que QIP fait 35 Mo? D'accord, 35 Mo est probablement trop, et cela devrait être réglé, mais ma note n'est pas à ce sujet. Nous parlons maintenant de Skype. Pourquoi utilise-t-il autant de ressources - près de 5 fois plus que QIP? C’est un peu trop pour un formulaire avec une liste de contacts, non?

Fait intéressant, ce problème ne me concerne pas seulement, si vous vous connectez à Google " Pourquoi skype consomme-t-il autant de mémoire ", alors il ne restera plus qu'un tas de discussions sur les forums pour lesquelles les nouvelles versions de Skype pèsent autant. Les réponses sont particulièrement agréables. Par exemple, une vraie réponse sur le forum de la communauté Skype (je cite ma traduction gratuite de la réponse):

, ? 4-8 . 140 , .

Ouais Oui. Bien sûr. Si c'est le cas de tous les développeurs de logiciels, alors de cette façon " aucun volost ne suffit pas ". La question n'est pas que je suis désolé pour la mémoire Skype (et je suis désolé aussi). La question est, qu'est-ce qui est si nouveau dans les fonctionnalités ajoutées aux nouvelles versions de Skype (par rapport aux anciennes), qu'elles nécessitent tellement de mémoire?

Mais ça va. J'étais plus intéressé par une autre question - le processeur avec Skype en arrière-plan ne s'est pas vraiment relaxé non plus et montrait périodiquement même une pleine charge. La question se pose: «Pourquoi et comment s'en débarrasser?». En fait, la question devrait ressembler à ceci - comment les développeurs parviennent-ils à créer de telles applications volumineuses? Et qu'en faire?

Un peu d'histoire

Bien sûr, tout visiteur de ce site a probablement entendu parler au moins une fois de la loi de Moore sur l’amélioration des performances du système. L'article Le déjeuner gratuit est terminé fournit une image si curieuse:



Comme vous pouvez le voir, quelque part en 2004, les processeurs ont atteint le plafond en termes de fréquence d'horloge. Et au cours des 10 dernières années, cette fréquence n'a pas particulièrement augmenté. En résulte-t-il que la loi de Moore a cessé d'être respectée? En fait, non, et l'article explique clairement et clairement pourquoi. Simplement, les performances de nos ordinateurs augmentent désormais en raison d'autres facteurs (cache et multicœur). Le hic, cependant, est que les applications monothread normales ne pourront pas accélérer ces facteurs. Et voici le problème. Le fait est que de nombreux fabricants de logiciels se comportent aujourd'hui comme si la cour était encore dans les années 80 ou 90, et l'optimisation du logiciel en termes de réduction du nombre de cycles d'horloge ne pose pas de problème particulier - vous pouvez simplement attendre un peu et les processeurs Plus vite.

Cela est vrai non seulement pour Microsoft, mais je vais me concentrer sur des exemples spécifiques. Joel Spolsky dans son article mentionne que Microsoft a réussi à l'emporter sur Lotus dans les années 80 dans la bataille entre Excel et 123 en raison du fait que les gestionnaires de Lotus ont fait une erreur critique - ils ont essayé d' optimiser l' application. Plus précisément, ils ont essayé de réduire l'application afin qu'elle soit toujours garantie de tenir dans 640 Ko de RAM. Ils l'ont tué pendant un an et demi, et pendant ce temps, Redmond a conquis le marché en utilisant Excel, car à ce moment-là, des ordinateurs avec des quantités de RAM beaucoup plus importantes étaient en service. Cette solution a coûté beaucoup à Lotus.

Cependant, voici ce qui est intéressant - de nos jours, une telle stratégie, peut-être, pourrait s'avérer être une victoire - puisque les ressources des systèmes de bureau standard n'augmentent plus à un rythme aussi incroyable qu'il y a 20-30 ans. Le problème est qu'en raison de la concurrence féroce de cette période, les entreprises qui ont développé la fonctionnalité des applications ont été les gagnantes, tout en ignorant les performances et l'optimisation. Ce sont ces entreprises qui ont formé cette idéologie de développement, dont nous récoltons encore les fruits.

Inflation

À quoi cela a-t-il conduit? À un phénomène très curieux. Je n'abandonnerai jamais les mises à niveau matérielles, mais tout à coup, récemment, j'ai commencé à éviter les mises à niveau logicielles inutilement, en raison d'une possible inflation . Par ce terme, je veux dire que le même ensemble fonctionnel que j'avais dans l'ancienne version, dans la nouvelle, j'obtiens pour un grand prix en termes de ressources processeur et de RAM.

Il y a un idiome constant en anglais, qui en russe ressemble à "essayer de réparer quelque chose qui n'a pas été brisé". La situation des logiciels au cours des 10 dernières années rappelle très bien cet idiome. Skype en est l'un des meilleurs exemples. A en juger par les forums, ce problème de mémoire n'existait pas dans les anciennes versions de Skype, par exemple, dans les versions 3.x. Qu'est-ce qui a été amélioré dans le produit depuis qu'il est devenu si cher en termes de RAM?

La même chose, en passant, s'applique à diverses applications de chat. Il y a environ 15 ans, le chat, qui à un moment occupe 30 Mo de RAM, ressemblait à un non-sens. Cependant, maintenant c'est déjà la norme, bien que nous fournisse les forums de discussion actuels, qui n'étaient pas fournis à l'époque?

N'oubliez pas Microsoft Office. À mon avis, la version pour XP a satisfait tout le monde. Bien sûr, comme tout produit, il avait ses inconvénients. Mais étaient-ils si critiques qu'ils devaient publier les versions 2007, 2010, etc.? J'y fais les mêmes documents, mais maintenant je dois attendre beaucoup plus longtemps jusqu'à ce que ces systèmes démarrent.

Pour justifier, nous entendons que les nouvelles versions contiennent de nouvelles fonctionnalités. Oui, je ne le nie pas, mais ne semble-t-il pas étrange que ce faisant, les anciennes opportunités nécessitent plus de ressources?

Modularité et optimisation

Mais pourquoi plus de ressources? Ici tout s'explique par le fait que la plupart des applications sont plutôt monolithiques. Non, en termes d'organisation du code, ils sont probablement décomposés en modules avec la bonne répartition des responsabilités. Cependant, je les appelle monolithiques dans le sens où lors du chargement d'une application, tous ses modules sont généralement chargés immédiatement, bien que cela ne soit souvent pas nécessaire.

Nous reviendrons à nouveau sur Skype. Maintenant, il est évidemment fait pour qu'avec une simple connexion, beaucoup de modules soient immédiatement chargés dans la RAM, qui sont directement responsables du son, de la vidéo, etc. Ceci malgré le fait que l'entrée habituelle ne nécessite qu'une liste d'utilisateurs et la possibilité d'échanger du texte. Ce système pourrait être fait différemment, ne chargeant que les plus nécessaires. Et seulement lorsque l'utilisateur veut vraiment démarrer un échange vidéo, tout le reste est chargé.

L'optimisation est également importante, car les développeurs ne peuvent pas développer physiquement tout le code «à partir de zéro», mais sont obligés d'utiliser des bibliothèques existantes qui ont été écrites sans trop de pression sur l'optimisation.

Imaginez que le développeur de chaque bibliothèque ait ralenti sa bibliothèque de 5% par rapport à ce qu'il aurait pu être s'il avait consacré des efforts supplémentaires à l'optimisation. Laissons la bibliothèque 1 utiliser la bibliothèque 2 dans son travail, et cette bibliothèque 3, et cette bibliothèque 4. Dans ce cas, une chaîne de 15 bibliothèques en cas d'accumulation de retards obtient le résultat 1.05 ^ 15 = 2.07, c'est-à-dire dans le pire des cas, l'application s'exécutera deux fois plus lentement que n'importe lequel des composants.

Je connais bien la phrase selon laquelle l'optimisation prématurée est la racine de tout mal. Cependant, il s'agit d'une optimisation prématurée, pas du tout d'optimisation. Ce slogan était merveilleux à une époque où les processeurs devenaient de plus en plus rapides devant nos yeux. Après avoir atteint le plafond, ce slogan commence à tourner sur le côté, lorsque l'ancienne version de l'application, écrite il y a environ 15 ans, commence soudain à paraître plus préférable que la version publiée la semaine dernière. Soit dit en passant, on ne peut manquer de noter que, souvent, les fabricants de logiciels tentent de forcer les utilisateurs à mettre à jour les logiciels, précisément parce qu'il n'y a pas de motifs particuliers pour le bénéfice du consommateur dans ce cas.

Exemples alternatifs

En principe, l'industrie du logiciel attend la même chose que l'industrie automobile après la crise pétrolière des années 70, quand il est devenu clair que l'essence devenait une ressource extrêmement coûteuse. Depuis lors, les constructeurs automobiles ont pu réduire la consommation de moteur d'environ un tiers, si je ne me trompe pas.

Dans le monde du logiciel, il existe également de tels exemples. À un moment donné, j'ai vraiment aimé Erlang, qui est construit sur le concept de nombreux processus légers indépendants qui ne sont unis que par des messages communs (cela vous permet de maximiser l'utilisation du multicœur). De plus, il y a un principe dans cet environnement qui a été explicitement emprunté aux interprètes LISP - que chaque module et fonction peut être chargé et rechargé en déplacement si nécessaire (et il en va de même pour tout processus).

À titre de comparaison, sur Glassfish, si vous avez changé l'une des centaines ou des milliers de classes, vous devez réinstaller l'intégralité du module (war / ear / jar). L'échange à chaud de fonctions ou de classes sur le pouce est là, mais il est très mal implémenté par rapport à Erlang.

L'avenir de l'industrie réside dans les applications qui peuvent utiliser pleinement la technologie multicœur et ne téléchargent pas immédiatement tous les modules possibles pour toutes les fonctionnalités de ce produit. Ceux. le programme pourra charger dans la configuration de base et consommer autant de ressources que son prédécesseur consommait il y a 15 ans, et si nécessaire, télécharger tout ce dont l'utilisateur a besoin en déplacement.