Si vous travaillez dans des domaines réellement critiques en termes de performances, vous ne pouvez pas reporter l'efficacité après coup. C'est l'une des choses les plus critiques à prendre en compte lors de la conception dès le début dans ces cas et de manière liée à la maintenabilité du résultat final.
Vous ne pouvez pas concevoir et implémenter un serveur à grande échelle et simplement commencer à écrire du code facile et bien documenté qui utilise simplement des fonctions de blocage pour tout avec un verrou de thread global qui verrouille l'ensemble du système pour traiter chaque demande client individuelle sans en mettre aucune pensé que ce soit en état partagé, en conflit de fils et en asynchronicité. C'est une recette pour un désastre et un besoin de repenser et de réécrire la majeure partie du code bien documenté que vous avez écrit de manière à conduire à la base de code la plus difficile à maintenir imaginable, en proie à des conditions de concurrence et des blocages à la suite d'essais pour atteindre l'efficacité requise avec le recul, au lieu d'avoir simplement pensé à des conceptions efficaces, simples et fonctionnelles dès le départ.
Une équipe de développement de jeux en 8 mois de production avec un moteur qui ne fait que 2 images par seconde sur leur matériel le plus costaud avec 32 cœurs tout en ayant tendance à caler pendant 15 secondes chaque fois que l'écran est occupé, il est peu probable d'obtenir instantanément un produit utilisable par juste correction d'un petit hotspot localisé. Il y a des chances que leur conception soit FUBAR d'une manière qui justifie une revisite épique de la planche à dessin et des changements de conception qui pourraient se répercuter dans tous les coins de la base de code.
Avec John Carmack, il a parlé une fois de la façon dont une démonstration technologique doit fonctionner au minimum de centaines à des milliers d'images par seconde afin de l'intégrer dans la production. Ce n'est pas une obsession malsaine pour l'efficacité. Il sait d'emblée que les jeux doivent fonctionner, dans leur intégralité, à plus de 30 FPS pour que les clients le trouvent acceptable. En conséquence, un petit aspect comme un système d'ombre douce ne peut pas fonctionner à 30 FPS, ou bien le jeu dans son ensemble ne peut pas être assez rapide pour fournir la rétroaction en temps réel requise. Il est inutilisable jusqu'à ce qu'il atteigne l'efficacité requise. Dans ces domaines où les performances sont critiques et où il y a une exigence fondamentale d'efficacité, une solution qui ne parvient pas à atteindre une vitesse adéquate n'est en fait pas meilleure qu'une solution qui ne fonctionne pas du tout,. Et vous ne pouvez pas concevoir un système d'ombre douce efficace qui s'exécute à des centaines à des milliers d'images par seconde comme requis pour un moteur de jeu en temps réel à moins que vous ne mettiez en avant une quantité prédominante de réflexion quant à son efficacité. En fait, dans de tels cas, 90% du travail est axé sur l'efficacité car il est trivial de proposer un système d'ombre douce qui fonctionne très bien à 2 heures par image en utilisant le traçage de chemin, mais vous ne pouvez pas vous attendre à le régler pour fonctionner à des centaines d'images par seconde sans changement totalement différent d'approche.
Lorsque l'efficacité est un élément fondamental de la conception d'une application, vous ne pouvez pas vous attendre à une efficacité avec le recul sans perdre considérablement plus de temps que vous n'en avez économisé en l'ignorant, car vous ne pouvez pas vous attendre à réaliser une conception fonctionnelle avec le recul. Personne ne dit: "Je peux remettre la conception à plus tard. Il suffit de bien documenter votre code et vous pourrez trouver une conception appropriée plus tard ." Mais dans les architectures à performances critiques, c'est ce que vous faites efficacement si vous ne faites pas beaucoup attention et réfléchissez à des conceptions efficaces dès le départ.
Maintenant, cela ne signifie pas que vous devez micro-régler vos implémentations dès le départ. Pour les détails de mise en œuvre, il y a beaucoup de place pour itérer vers des solutions plus rapides après la mesure, à condition que la conception n'ait pas besoin de changer, et c'est souvent la façon la plus productive de s'y prendre. Mais au niveau de la conception, cela signifie que vous devez réfléchir suffisamment à la façon dont la conception et l'architecture seront liées à l'efficacité dès le départ.
La principale différence ici est le design. Il n'est pas facile d'apporter de grands changements aux conceptions avec le recul, car les conceptions accumulent des dépendances et les dépendances se briseront si la conception change. Et si une conception doit être raisonnablement efficace ou, dans certains cas, que sa qualité est largement mesurée par son efficacité, alors vous ne devriez pas vous attendre à pouvoir réaliser une conception appropriée après coup. Avec tous les produits compétitifs où l'efficacité est un énorme aspect de la qualité, qu'il s'agisse de systèmes d'exploitation ou de compilateurs ou de processeurs vidéo ou de raytracers ou de moteurs de jeu ou de moteurs physiques, les réflexions sur l'efficacité et les représentations de données ont été méticuleusement pensées dès le début. Et dans ces cas, ce n'est pas une optimisation prématurée de mettre autant de réflexion sur l'efficacité dès le départ. Il plaçait une telle pensée exactement au moment le plus productif pour le faire,