L'évolution progressive de la méthodologie de la rédaction a-t-elle affecté la performance du système? Et devrais-je me soucier?
TD; DR :
Il y avait une certaine confusion quant à ce que je demandais, alors voici l'idée de conduite derrière la question:
J'ai toujours voulu que la question soit ce qu'elle est. Je ne l'ai peut-être pas articulé bien à l'origine. Mais l'intention a toujours été " est modulaire, séparé, couplé, découplé, de code refactored " nettement plus lentement de sa propre nature que " Unité monolithique simple, tout en un seul endroit, un fichier, étroitement couplé "Code. Le reste n'est que des détails et diverses manifestations de cela que je suis tombée à travers ou maintenant ou plus tard. Il est plus lent à une certaine échelle. Comme un disque non défragé, vous devez récupérer les morceaux de partout. C'est plus lent. Avec certitude. Mais devrais-je m'occuper?
Et la question n'est pas à propos de ...
pas sur la micro-optimisation, l'optimisation prématurée, etc. Il ne s'agit pas de "optimiser ceci ou cette partie à mort".
Qu'est-ce que c'est alors?
Il s'agit de la méthodologie globale et des méthodes de réflexion sur le code d'écriture qui émergeait avec le temps:
- "Injectez ce code dans votre classe comme une dépendance"
- "Ecrire un fichier par classe"
- "Séparez votre vue de votre base de données, de votre contrôleur, de votre domaine".
- n'écrivez pas Spaghetti Homogène SingleBlock, mais écrivez de nombreux composants modulaires séparés qui fonctionnent ensemble
Il s'agit de la manière et du style du code qui est actuellement - au cours de cette décennie - vu et préconisé dans la plupart des cadres, préconisé aux conventions, adoptée par la communauté. C'est un changement de réflexion de "blocs monolithiques" aux "microservices". Et avec cela vient le prix en termes de performances et de frais généraux au niveau de la machine, ainsi que des frais généraux de niveau de programmeur également.
La question originale suit :
Dans le domaine de l'informatique, j'ai remarqué un changement remarquable de penser en matière de programmation. Je rencontre le conseil assez souvent qui va comme ça:
- écrire un code de fonction inférieur (plus testable et maintenu de cette façon)
- refacteur du code existant dans des morceaux de code plus petits et plus petits jusqu'à la majeure partie de vos méthodes/fonctions ne correspond que quelques lignes de long et il est clair ce qui est leur but (qui crée plus de fonctions, comparées à un bloc monolithique plus grand)
- ecrire des fonctions qui ne font qu'une chose - la séparation des préoccupations, etc. (qui crée généralement plus de fonctions et plus de cadres sur une pile)
- créer plus de fichiers (une classe par fichier, plus de classes à des fins de décomposition, telles que MVC, architecture de domaine, motifs de conception, OO, etc., qui crée plus d'appels de systèmes de fichiers)
C'est un changement par rapport aux pratiques de codage "anciennes" ou "obsolètes" ou "spaghetti" où vous avez des méthodes couvrant 2500 lignes, ainsi que de grandes classes et des objets de Dieu qui font tout.
ma question est la suivante :
lorsque l'appel it est descendu au code de la machine, aux instructions d'assemblage, aux plateaux de disque dur, devrais-je être du tout concerné que mon parfaitement séparé de classe OO code avec une variété de petits réduits -à de minuscules fonctions et méthodes génère trop de frais généraux supplémentaires?
Détails
Bien que je ne connaisse pas intimement comment OO Code et ses appels de méthode sont traités dans l'ASM à la fin et comment les appels de dB et les appels de compilateur se traduisent au bras d'actionneur en mouvement sur un plateau de disque dur, je fais avoir une idée. Je suppose que chaque appel de fonction supplémentaire, appel d'objet ou "#include" appelle (dans certaines langues), générez un ensemble d'instructions supplémentaires, augmentant ainsi le volume de code et l'ajout de divers "câblages de code", sans ajouter de code "utile" réel . J'imagine également que de bonnes optimisations peuvent être faites à l'ASM avant qu'il ne soit réellement dirigé sur le matériel, mais cette optimisation ne peut le faire que bien trop.
Par conséquent, ma question - combien de frais généraux (dans l'espace et à la vitesse) correspond à un code bien séparé (code qui est divisé sur des centaines de fichiers, de classes et de motifs de conception, etc.) introduisent en réalité par rapport à "une grande méthode qui contient tout dans un fichier monolithique ", en raison de cette surcharge?
Mise à jour de la clarté :
Je suppose que prendre le même code et le diviser, le refactorisant, le découplage dans de plus en plus de fonctions et d'objets et de méthodes et de classes entraîneront De plus en plus Paramètre Passage entre les pièces de code plus petites. Parce que, à coup sûr, le code de refactoring doit conserver le fil, et cela nécessite le passage du paramètre. Plus de méthodes ou plus de classes ou plus de méthodes de conception de méthodes d'usine, entraîne plus de frais de transmission de divers bits d'informations plus que ce soit le cas dans un seul monolithique classe ou méthode.
Il a été dit quelque part (citation tbd) que jusqu'à 70% de tout code est composé de l'instruction MOV d'ASM - chargement des registres de la CPU avec des variables appropriées, et non le calcul réel effectué. Dans mon cas, vous chargez le temps de la CPU avec des instructions PUSH/POP pour fournir un lien et un paramètre passant entre diverses pièces de code. Plus vous faites de vos pièces de code, plus vous avez besoin de "linkage" sur le dessus. Je suis préoccupé par le fait que ce lien ajoute à un ballonnement logiciel et à la ralentissement et je me demande si je devrais m'inquiéter de cela, et combien, le cas échéant, parce que les générations actuelles et futures de programmeurs qui construisent des logiciels pour le siècle prochain , devra vivre avec et consommer des logiciels construits en utilisant ces pratiques.
Mise à jour: plusieurs fichiers
J'écris un nouveau code maintenant qui remplace lentement l'ancien code. En particulier, j'ai noté que l'une des anciennes classes était un fichier de 3000 lignes (comme mentionné précédemment). Maintenant, il est en train de devenir un ensemble de fichiers de 15 à 20 situés sur divers répertoires, y compris des fichiers de test et non inclus PHP Cadre, j'utilise pour lier certaines choses ensemble. Plusieurs fichiers arrivent également. Quand Il s'agit sur le disque d'E/S, chargement de plusieurs fichiers est plus lent que le chargement d'un fichier volumineux. Bien sûr que tous les fichiers sont chargés, ils sont chargés au besoin, ainsi que des options de mise en cache de disque et de mémoire de mémoire, et pourtant, je crois toujours que loading multiple files Prend plus de traitement que loading a single file En mémoire. Je ajoute cela à ma préoccupation.
Mise à jour: la dépendance injecte tout
Revenir à cela après un moment .. Je pense que ma question était mal comprise. Ou peut-être que j'ai choisi de mal comprendre certaines réponses. Je ne parle pas de micro-optimisation car certaines réponses ont été distinguées (au moins, je pense que appeler ce que je parle de micro-optimisation est un abu), mais sur le mouvement du "code de refacteur pour desserrer le couplage serré", dans son ensemble , à chaque niveau du code. Je viens de Zend Con juste récemment où ce style de code a été l'un des points centraux et des centres de centre de la Convention. Decouple Logic de la vue, Affichage du modèle, modèle de base de données, et si vous le pouvez, découplez des données de la base de données. Dépendance - injecte tout, ce qui signifie parfois juste ajouter un code de câblage (fonctions, classes, chaudières) qui ne rien , mais sert de point de couture/crochet, Doubler facilement la taille du code dans la plupart des cas.
Mise à jour 2: "Séparer le code en plus de fichiers" affecte de manière significative les performances (à tous les niveaux de calcul)
Comment la philosophie de compartmentalize your code into multiple files Est-elle informatique d'aujourd'hui (performances, utilisation de disque, gestion de la mémoire, tâches de traitement de la CPU)?
Je parle de
avant ...
Dans un passé hypothétique mais très réel pas si lointain, vous pouvez facilement écrire un mono-block d'un fichier qui comporte des modèles et des spaghettis et de contrôleur spaghetti ou non-spaghetti, mais qui fonctionne Tout Une fois qu'il est déjà chargé. Faire des points de repère dans le passé en utilisant C Code, j'ai découvert qu'il est beaucoup plus rapide de charger un seul fichier de 900 Mo en mémoire et de le traiter dans de grandes morceaux que de charger un tas de fichiers plus petits et de les traiter dans un repas de paix plus petit. des morceaux faisant le même travail à la fin.
.. et maintenant *
Aujourd'hui, je me trouve à la recherche du code qui montre un grand livre, qui comporte des fonctionnalités telles que. Si un élément est un "ordre", affiche le bloc HTML de la commande. Si un élément de ligne peut être copié, imprimez le bloc HTML qui affiche une icône et des paramètres HTML derrière cela vous permettant de faire la copie. Si l'élément peut être déplacé vers le haut ou le bas, affichez les flèches HTML appropriées. Etc. Je peux, via Zend Framework Create partial() appels, ce qui signifie essentiellement "Appeler une fonction qui prend vos paramètres et les insère dans un fichier HTML distinct qui appelle également". Selon votre détail, je veux obtenir, je peux créer des fonctions HTML séparées pour les parties les plus petites du grand livre. Un pour la flèche vers le haut, la flèche vers le bas, un pour "Puis-je copier cet élément", etc. Créez facilement plusieurs fichiers pour afficher une petite partie de la page Web. Prendre mon code et mon code Zend-Framework, le système/la pile appelle probablement près de 20-30 fichiers différents.
quoi?
Je suis intéressé par les aspects, le usure sur la machine créée par la compartimentation du code dans de nombreux fichiers distincts plus petits.
Par exemple, le chargement d'autres fichiers signifie qu'ils sont situés dans divers endroits du système de fichiers et dans divers endroits de disque dur physique, ce qui signifie plus de cours de recherche et de lecture de disque dur.
Pour la CPU, cela signifie probablement plus de basculement de contexte et de chargement de divers registres.
Dans ce sous-bloc (Mise à jour n ° 2), je suis intéressé à savoir comment utiliser plusieurs fichiers pour effectuer les mêmes tâches pouvant être effectuées dans un seul fichier, affectez les performances du système.
tilisation de Zend Form API VS simple HTML
J'ai utilisé Zend Form API avec les derniers et les plus grands modernes OO PRATIQUES, pour créer un formulaire HTML avec validation, transformer POST en objets de domaine.
Il m'a fallu 35 fichiers pour le faire.
35 files =
= 10 fieldsets x {programmatic fieldset + fieldset manager + view template}
+ a few supporting files
Tout ce qui pourrait être remplacé par un quelques simples fichiers HTML + PHP + JS + CSS, peut-être total de 4 fichiers légers-poids.
Est-ce mieux? Est-ce pire? ... Imaginez charger 35 fichiers + de nombreux fichiers de bibliothèque Zend Zramework qui les font fonctionner, vs 4 fichiers simples.
Sans soins extrêmes, la micro-optimisation telle que ces préoccupations conduit à un code non stimulaire.
Initialement, cela ressemble à une bonne idée, le profileur vous dit que le code est plus rapide et V & V/Test/QA indique même des œuvres. Des bugs se trouvent rapidement, les exigences changent et les améliorations jamais considérées sont demandées.
Sur la vie d'un code de projet se dégrade et devient moins efficace. Le code maintenu deviendra plus efficace que son homologue non restauré car il se dégradera plus lentement. La raison est que le code construit l'entropie tel qu'il est changé -
Le code non saintable a rapidement plus de code mort, de chemins redondants et de duplication. Cela conduit à plus de bugs, créant ainsi un cycle de dégradation du code - y compris ses performances. Avant de long, les développeurs ont une faible confiance que les changements qu'ils rendent sont corrects. Cela les ralentit, rend la prudence et conduit généralement à encore plus d'entropie lorsqu'ils ne traitent que des détails qu'ils peuvent voir
Le code maintenu, avec de petits modules et des tests unitaires, il est plus facile de modifier, le code qui n'est plus nécessaire est plus facile à identifier et à supprimer. Le code qui est cassé est également plus facile à identifier, peut être réparé ou remplacé par la confiance.
Ainsi, à la fin, cela revient à la gestion du cycle de vie et n'est pas aussi simple que "c'est plus rapide, il sera donc toujours plus rapide".
Surtout, le code correct lent est infiniment plus rapide que le code incorrect rapide.
Ceci est un changement par rapport aux "anciennes" ou "mauvaises" pratiques de code où vous avez des méthodes couvrant 2500 lignes et de grandes classes qui font tout.
Je ne pense pas que quiconque ait jamais pensé que c'est une bonne pratique. Et je doute que les gens qui l'avaient fait pour des raisons de performance.
Je pense que la célèbre citation de Donald Knuth est très pertinente ici:
Nous devrions oublier de petites gains d'efficacité, dire environ 97% du temps: l'optimisation prématurée est la racine de tout mal.
Donc, dans 97% de votre code, utilisez simplement de bonnes pratiques, écrivez de petites méthodes (quelle est la petite question d'opinion, je ne pense pas que toutes les méthodes ne soient que quelques lignes), etc. pour les 3% restants, où les performances la matière, mesure IT. Et si les mesures montrent que de nombreuses petites méthodes ralentissent considérablement votre code, vous devriez les combiner dans des méthodes plus grandes. Mais n'écrivez pas un code systématisable juste parce qu'il pourrait être plus rapide.
Vous devez faire attention à écouter les programmeurs expérimentés ainsi que la pensée actuelle. Les personnes qui ont traité des années avec des logiciels massifs ont quelque chose à contribuer.
Dans mon expérience, voici ce qui conduit à des ralentissements et ils ne sont pas petits. Ils sont des ordres de grandeur:
L'hypothèse selon laquelle toute ligne de code prend à peu près autant de temps que tout autre. Par exemple
cout << endlcontrea = b + c. Le premier prend des milliers de fois de plus de plus que ce dernier. Stackexchange a beaucoup de questions de la forme "J'ai essayé différentes manières d'optimiser ce code, mais cela ne semble pas faire une différence, pourquoi pas?" quand il y a un appel de la bonne fonction au milieu de celui-ci.L'hypothèse selon laquelle une fonction ou un appel de méthode, une fois écrite, est bien sûr nécessaire. Les fonctions et les méthodes sont faciles à appeler et l'appel est généralement assez efficace. Le problème est qu'ils sont comme des cartes de crédit. Ils vous tentent de dépenser plus que ce que vous voulez vraiment, et ils ont tendance à cacher ce que vous avez dépensé. En plus de cela, le grand logiciel comporte des couches sur des couches d'abstraction, de sorte que même s'il n'y a que 15% de déchets à chaque couche, plus de 5 couches qui se composent à un facteur de ralentissement de 2. La réponse à cela ne doit pas supprimer la fonctionnalité ou l'écriture Fonctions plus grandes, il est de discipliner vous-même d'être sur la garde pour ce problème et (( être disposé et capable de le racine .
Généralité galopante. La valeur de l'abstraction est que cela peut vous laisser faire plus avec moins de code - au moins c'est l'espoir. Cette idée peut être poussée à l'extrême. Le problème avec trop de généralité est que chaque problème est spécifique et lorsque vous le résolvez avec des abstractions générales, ces abstractions ne sont pas nécessairement capables d'exploiter les propriétés spécifiques de votre problème. Par exemple, j'ai vu une situation dans laquelle une classe de file d'attente prioritaire fantaisie, qui pourrait être efficace aux grandes tailles, a été utilisée lorsque la longueur n'a jamais dépassé 3!
Structure de données galopant. =OOP est un paradigme très utile, mais cela n'encourage pas à minimiser la structure de données - il encourage plutôt celui d'essayer de cacher la complexité de celui-ci. Par exemple, il existe le concept de "notification" "Où si Datum A est modifié d'une certaine manière, un événement de notification de manière à ce que B et C puisse également se modifier de manière à maintenir l'ensemble de l'ensemble cohérent. Cela peut se propager sur plusieurs couches et amplifier énormément le coût de la modification extrêmement. Ensuite, il est tout à fait possible que la modification d'A pourrait bientôt après être annulée ou modifiée pour une autre modification, ce qui signifie que les efforts consacrés à essayer de garder le Ensemble cohérent encore à faire. Confusion qui constitue la probabilité de bugs dans toutes ces manuelles de notification, ainsi que la circularité, etc. Il est de loin préférable d'essayer de garder la structure de données normalisée, de sorte que tout changement doit être effectué dans une endroit seulement. Si des données non normalisées ne peuvent pas être évitées, il est préférable d'avoir des passages périodiques à re Associez l'incohérence plutôt que de prétendre que cela peut rester conforme à une courte laisse.
... Quand je pense à plus, je l'ajouterai.
La reponse courte est oui". Et, généralement, le code sera un peu plus lent.
Mais parfois, un refactoring OO-ISH approprié révélera des optimisations qui rendent le code plus rapidement. J'ai travaillé sur un projet où nous avons fait un complexe =Java ALGORITHM beaucoup plus OO-ISH, avec des structures de données appropriées, des getters, etc. au lieu de matrices imbriquées désordonnées d'objets. Mais, en isolant et Limiter l'accès aux structures de données, nous avons pu passer de baies géantes de doubles (avec des nulls pour des résultats vides) à des tableaux plus organisés de doubles, avec des nans pour des résultats vides. Cela a donné un gain de 10x à la vitesse.
Addenda: En général, un code structuré plus petit et plus élevé devrait être plus préalable à la multi-threading, votre meilleur moyen d'obtenir des accélérations majeures.
Entre autres choses, la programmation concerne les compromis . Basé sur ce fait, je vous incline pour répondre oui, c'est pourrait être plus lentement. Mais pensez à ce que vous obtenez en retour. Obtenir un code lisible, réutilisable et facilement modifiable est facilement surpassable à tous les inconvénients éventuels.
AS @ user949300 mentionné , il est plus facile de repérer les zones pouvant être améliorées algorithmiquement ou architecturales avec une telle approche; L'amélioration de ceux-ci sont généralement beaucoup plus bénéfiques et efficaces que de ne pas avoir possible OO ou frais de surcharge d'appel de fonction (qui n'est déjà juste un bruit, je parie).
J'imagine également que de bonnes optimisations peuvent être faites à l'ASM avant qu'elle ne soit réellement couru sur le matériel.
Chaque fois que quelque chose aime cela croise mon esprit, je me souviens que des décennies dépensées par les personnes les plus intelligentes travaillant sur des compilateurs sont probablement des outils comme GCC bien mieux que moi lors de la génération de code de machine. Sauf si vous travaillez sur une sorte de trucs liés aux microcontrôleurs, je vous suggère de ne pas vous inquiéter.
Je suppose que l'ajout de plus en plus de fonctions et de plus en plus d'objets et de classes dans un code entraîneront de plus en plus de paramètres passant entre des pièces de code plus petites.
En supposant que quelque chose lors de l'optimisation est une perte de temps, vous avez besoin de faits sur la performance du code. Trouvez où votre programme passe la plupart du temps avec des outils spécialisés, optimiser cela, itérair.
Pour tout résumer; Laissez le compilateur faire son travail, concentrez-vous sur des choses importantes comme l'amélioration de vos algorithmes et de vos structures de données. Tous les modèles que vous avez mentionnés dans votre question existent pour vous aider à vous aider, utilisez-les.
P.s: Ces 2 discussions de Crockford ont sauté dans ma tête et je pense qu'ils sont quelque peu liés. Le premier est la super brève histoire CS (qui est toujours bon à savoir avec toute science exacte); Et la seconde, c'est pourquoi nous rejetons de bonnes choses.
Je crois que les tendances que vous identifiez sur une vérité sur le développement de logiciels - le temps de programmeur est plus cher que le temps de la CPU. Jusqu'à présent, les ordinateurs n'ont obtenu que plus vite et moins cher, mais un gâchis enchevêtré d'une application peut prendre des centaines, voire des milliers d'heures d'homme à changer. Compte tenu du coût des salaires, des avantages, des bureaux, etc., il est plus rentable d'avoir du code qui pourrait être exécuté un peu plus lent mais plus rapide et plus sûr de changer.
Eh bien 20 ans, il y a plus de 20 ans, que je devine que vous n'appelez pas de nouveau et non "ancien ni mauvais", la règle était de garder des fonctions suffisamment petites pour s'adapter à une page imprimée. Nous avons eu des imprimantes matricielles de points, alors le nombre de lignes était donc quelque peu fixé, généralement un ou deux choix de lignes par page ... définitivement moins de 2500 lignes.
Vous demandez de nombreux aspects du problème, de la maintenabilité, de la performance, de la qualification, de la lisibilité. Plus vous vous penchez vers la performance, moins le code deviendra et lisible, vous devez donc trouver votre niveau de confort qui peut et variera pour chaque programmeur individuel.
En ce qui concerne le code produit par le compilateur (code de machine si vous voulez), plus la fonction est plus importante pour avoir besoin de changer de valeurs intermédiaires dans des registres à la pile. Lorsque les cadres de pile sont utilisés, la consommation de pile est en gros morceaux. Plus les fonctions sont plus petites, plus la possibilité de rester plus dans des registres et moins de dépendance à la pile. Des morceaux de pile plus petits nécessaires à la fonction naturellement. Les cadres de pile ont des avantages et des inconvénients pour la performance. Plus de fonctions plus petites signifie plus de configuration et de nettoyage de fonction. Bien sûr, cela dépend également de la compilation, quelles opportunités vous donnez le compilateur. Vous pouvez avoir 250 fonctions de ligne au lieu d'une seule fonction de ligne de 2500, la fonction de 1 2500 lignes que le compilateur va obtenir si elle peut/choisit d'optimiser dans l'ensemble. Mais si vous prenez ces 250 fonctions à 10 lignes et que vous les étalerez sur 2, 3, 4, 250 fichiers distincts, compilez chaque fichier séparément, le compilateur ne sera pas capable d'optimiser presque autant de code mort tel qu'il aurait pu. L'essentiel ici est qu'il y a des avantages et des inconvénients aux deux et il n'est pas possible de mettre une règle générale à ce sujet ou c'est le meilleur moyen.
Les fonctions de taille raisonnables, une personne peut voir sur un écran ou une page (dans une police raisonnable), est quelque chose qu'ils peuvent consommer mieux et comprendre que le code assez grand. Mais s'il s'agit simplement d'une petite fonction avec des appels vers de nombreuses autres petites fonctions qui appellent de nombreuses autres petites fonctions dont vous avez besoin de plusieurs fenêtres ou navigateurs pour comprendre ce code, vous n'avez rien acheté sur le côté lisibilité.
la manière Unix est de faire utiliser mon terme, des blocs LEGO joliment polis. Pourquoi utiliseriez-vous une fonction de bande cela plusieurs ans après avoir arrêté d'utiliser des bandes? Parce que le blob a très bien fait son travail et à l'arrière, nous pouvons remplacer l'interface de la bande avec une interface de fichier et tirer parti de la viande du programme. Pourquoi réécrire le logiciel de gravure CDROM simplement parce que SCSI s'est éloigné comme l'interface dominante remplacée par l'IDE (puis revenir plus tard). Encore une fois, prenez l'advanattage des sous-blocs polis et remplacez une extrémité par un nouveau bloc d'interface (comprenez également les concepteurs matériels classés simplement sur un bloc d'interface sur les conceptions matérielles dans certains cas, la fabrication d'un lecteur SCSI a une interface IDE à SCSI. Pour raccourcir cette , Construisez des blocs LEGO poli de taille raisonnable, chacun avec des entrées et des sorties bien définies bien définies. Vous pouvez envelopper des tests autour de ces blocs LEGO, puis prenez le même bloc et d'envelopper l'interface utilisateur et les interfaces d'utilisation du même bloc autour du même bloc et du bloc, en théorie étant bien testé et bien compris ne doit pas nécessiter de déboguer, juste les nouveaux blocs supplémentaires ajoutés à chaque extrémité. Tant que toutes vos interfaces de blocs sont bien conçues et que la fonctionnalité bien comprise, vous pouvez construire de nombreuses choses avec un minimum si Toute colle. Tout comme avec des blocs bleus et rouges et noirs et jaunes de tailles et de formes connues, vous pouvez faire beaucoup de choses.
Chaque individu est différent, leur définition des variables polies et bien définies et testées et lisibles. Il n'est pas déraisonnable, par exemple, pour un professeur dicter des règles de programmation non pas parce qu'ils peuvent ou non être mauvais pour vous en tant que professionnel, mais dans certains cas, pour faciliter la lecture et la notation de votre code sur les assistants des étudiants du professeur ou des étudiants diplômés. ... Vous êtes également probable, professionnellement, de constater que chaque travail peut avoir des règles différentes pour diverses raisons, généralement une ou quelques personnes au pouvoir ont leur opinion sur quelque chose, juste ou mal et avec ce pouvoir qu'ils peuvent dicter que vous faites. Il y a de la voie (ou cessez-vous, soyez tiré ou d'une manière ou d'une autre). Ces règles sont aussi souvent basées sur l'opinion qu'ils sont basées sur une sorte de fait sur la lisibilité, la performance, la qualification, la portabilité.
Dépend à quel point votre compilateur est intelligent. En règle générale, essayer d'immerger l'optimiseur est une mauvaise idée et peut réellement voler le compilateur des possibilités d'optimiser. Pour commencer, vous n'avez probablement aucune idée de ce que vous pouvez faire et la plupart de ce que vous faites influencer réellement à quel point cela le fait aussi.
L'optimisation prématurée est la notion de programmeurs qui essaient de le faire et de se retrouver difficiles à maintenir le code qui n'était pas réellement sur le chemin critique de ce qu'ils essayaient de faire. En essayant de tirer autant de CPU que possible lorsque la plupart du temps, votre application est effectivement bloquée en attente IO événements, c'est quelque chose que je vois beaucoup par exemple.
Le mieux est de coder pour l'exactitude et d'utiliser un profileur pour trouver des goulots d'étranglement réels de performances et de les corriger en analysant ce qui est sur le chemin critique et s'il peut être amélioré. Souvent, quelques solutions simples vont très loin.
[élément d'ordinateur]
refactore-t-il au couplage de lâche et aux fonctions plus petites affectent la vitesse du code?
Oui. Mais il appartient aux interprètes, compilateurs et compilateurs JIT à dénuder ce code "couture/câblage", et certains le font mieux que d'autres, mais certains ne le font pas.
La préoccupation de plusieurs fichiers ajoute aux frais généraux d'E/S, de sorte que cela affecte également la vitesse également (en temps d'ordinateur).
[élément de vitesse humaine]
[.____] (et devrais-je m'occuper?)
non, vous ne devriez pas vous soucier. Les ordinateurs et les circuits sont assez rapides de nos jours et d'autres facteurs prennent la relève, tels que la latence de réseau, l'E/S de la base de données et la mise en cache.
Ainsi, 2x - 4x ralentissement de l'exécution du code natif lui-même sera souvent noyé par ces autres facteurs.
En ce qui concerne le chargement de plusieurs fichiers, cela est souvent pris en charge par diverses solutions de mise en cache. Cela peut prendre plus de temps pour charger les choses et les fusionner la première fois, mais pour chaque prochaine fois, pour les fichiers statiques, la mise en cache fonctionne comme si un seul fichier est chargé. La mise en cache est une solution au chargement de plusieurs fichiers.
la réponse (au cas où vous l'avez manqué)
Oui, vous devriez vous soucier, mais vous souciez de savoir comment vous écrivez le code et non sur la performance.
En bref
Ne vous souciez pas de la performance
Dans le contexte de la question, des compilateurs plus intelligents et des interprètes s'occupent déjà de cela
se souciez de l'écriture de code mainten
Code où les coûts de maintenance sont au niveau de la compréhension humaine raisonnable. Ie n'écrire pas 1000 fonctions plus petites rendant le code incompréhensible, même si vous comprenez chacun, et n'écrivez pas une fonction d'objet de Dieu trop grande pour comprendre, mais écrivez 10 fonctions bien conçues qui ont un sens à un humain, et sont facile à maintenir.