Je pourrais être partisan de travailler dans des domaines très critiques pour les performances comme le traitement d'image et le raytracing, mais je dirais quand même d'optimiser "le plus tard possible" . Quel que soit le niveau de performance de vos besoins, il y a toujours beaucoup plus d'informations et de clarté avec le recul, après avoir mesuré, qu'avant, ce qui signifie que même les optimisations les plus efficaces sont généralement appliquées plus tard après avoir acquis ces connaissances.
Cas particuliers
Mais parfois «aussi tard que possible» est encore assez sacrément tôt dans certains cas particuliers. Si nous parlons de rendus hors ligne, par exemple, les structures de données et les techniques que vous utilisez pour obtenir des performances s'infiltrent réellement dans la conception utilisateur. Cela peut sembler dégoûtant, mais le domaine est si avant-gardiste et si critique pour les performances que les utilisateurs acceptent des contrôles utilisateur spécifiques aux techniques d'optimisation applicables à un raytracer particulier (ex: mise en cache de l'irradiance ou cartographie des photons), car certains d'entre eux sont utilisés aux heures d'attente pour le rendu d'une image, et d'autres sont habitués à débourser d'énormes sommes d'argent pour louer ou posséder une ferme de rendu avec des machines dédiées au rendu. Il y a une réduction massive de temps et d'argent pour ces utilisateurs si un moteur de rendu hors ligne compétitif peut offrir une réduction non triviale du temps passé à rendre. C'est une sorte de domaine où une réduction de 5% du temps excite réellement les utilisateurs.
Dans de tels cas particuliers, vous ne pouvez pas choisir une technique de rendu à volonté et espérer l'optimiser plus tard, car la conception entière, y compris la conception utilisateur, tourne autour des structures de données et des algorithmes que vous utilisez. Vous ne pouvez pas nécessairement même vous contenter de ce qui a bien fonctionné pour d'autres personnes, car ici, vous, en tant qu'individu, et vos forces et faiblesses particulières, contribuez fortement à fournir une solution compétitive. L'état d'esprit et la sensibilité du développeur principal derrière Arnold sont différents de ceux travaillant sur VRay qui ont utilisé une approche très différente; ils ne peuvent pas nécessairement échanger des lieux / techniques et faire le meilleur travail (même s'ils sont tous les deux des leaders industriels). Vous devez genre d'expérimentation et de prototype et de référence et trouver ce que vous ' re particulièrement bon à faire étant donné l'éventail infini de techniques de pointe là-bas si vous espérez expédier quelque chose de compétitif qui se vendra réellement. Donc, dans ce cas particulier, les problèmes de performances remontent au premier plan comme peut-être la préoccupation la plus importante avant même de commencer le développement.
Pourtant, ce n'est pas nécessairement une violation de l'optimisation «le plus tard possible» , c'est juste «le plus tard possible», c'est plutôt tôt dans ces cas extrêmes et particuliers. Déterminer quand et aussi ce qui n'a pas besoin de problèmes de performances aussi précoces, voire jamais, est probablement le principal défi pour le développeur. Ce qu'il ne faut pas optimiser pourrait être l'une des choses les plus précieuses à apprendre et à continuer à apprendre dans la carrière d'un développeur, car vous ne pouvez pas manquer de développeurs naïfs qui veulent tout optimiser (et malheureusement, même certains vétérans qui ont réussi à garder leur travail d'une manière ou d'une autre) malgré leur contre-productivité).
Aussi tard que possible
La partie la plus difficile est peut-être d'essayer de comprendre ce que cela signifie. J'apprends toujours et je programme depuis près de trois décennies. Mais surtout maintenant dans ma troisième décennie, je commence à réaliser que ce n'est pas si difficile. Ce n'est pas sorcier, si vous vous concentrez davantage sur la conception que sur la mise en œuvre. Plus vos conceptions laissent une marge de manœuvre pour des optimisations appropriées plus tard sans modifications de la conception, plus tard vous pourrez optimiser. Et la productivité de plus en plus que j'ai gagné en recherchant de tels modèles qui me permettent de respirer.
Conception qui offre une marge respiratoire à optimiser plus tard
Ces types de conceptions ne sont en fait pas si difficiles à réaliser dans la plupart des cas si nous pouvons appliquer un certain "bon sens". En tant qu'histoire personnelle, je suis dans les arts visuels en tant que passe-temps (je trouve qu'il est quelque peu utile de programmer des logiciels pour les artistes étant un peu moi-même pour comprendre leurs besoins et parler leur langue), et j'ai passé du temps au début des années 2000 à utiliser des applets Oekaki en ligne comme un moyen rapide de griffonner et de partager mon travail et de se connecter avec d'autres artistes.
En particulier, mon site et mon applet préférés étaient criblés de défauts de performances (toute taille de pinceau non triviale ralentirait à l'exploration), mais avait une très belle communauté. Pour contourner les problèmes de performances, j'ai utilisé de minuscules pinceaux 1 ou 2 pixels et j'ai simplement griffonné mon travail comme suit:
Pendant ce temps, je continuais à donner à l'auteur du logiciel des suggestions pour améliorer les performances, et il a remarqué que mes suggestions étaient de nature particulièrement technique en ce qui concerne les optimisations de la mémoire et les algorithmes, etc. Il m'a donc demandé si j'étais programmeur et j'ai dit oui et il m'a invité à travailler sur le code source.
J'ai donc regardé le code source, l'ai exécuté, profilé, et à ma grande horreur, il avait conçu le logiciel autour du concept d'une "interface pixel abstraite", comme IPixel
, qui a fini par être la cause profonde derrière les meilleurs points chauds pour tout avec dynamique allocations et répartition pour chaque pixel de chaque image. Pourtant, il n'y avait aucun moyen pratique d'optimiser cela sans reconsidérer la conception de l'ensemble du logiciel, car la conception l'avait piégé dans un coin où il n'y a pas grand-chose au-delà de la plus triviale des micro-optimisations lorsque nos abstractions fonctionnent au niveau granulaire d'un seul pixel abstrait. et tout dépend de ce pixel abstrait.
Je pense que c'est une violation du "bon sens", mais ce n'était évidemment pas du bon sens pour le développeur. Mais c'est comme ne pas abstraire des choses à un niveau si granulaire où même les cas d'utilisation les plus élémentaires vont être instanciés par millions, comme avec des pixels ou des particules, ou de minuscules unités dans une simulation d'armée ginormous. Privilégiez le IImage
(vous pouvez gérer tous les formats d'image / pixel dont vous avez besoin à ce niveau d'agrégation plus volumineux) ou IParticleSystem
vers IPixel
ou IParticle
, et vous pouvez ensuite mettre en œuvre les implémentations les plus basiques et les plus rapides à écrire et simples à comprendre derrière de telles interfaces et avoir toute la marge de manoeuvre dont vous aurez besoin pour optimiser plus tard sans reconsidérer la conception complète du logiciel.
Et c'est le but que je vois ces jours-ci. À l'exception des cas particuliers tels que les rendus hors ligne ci-dessus, concevez avec suffisamment de marge de manœuvre pour optimiser le plus tard possible, avec autant d'informations rétrospectives que possible (y compris les mesures), et appliquez toutes les optimisations nécessaires le plus tard possible.
Bien sûr, je ne suggère pas nécessairement de commencer par utiliser des algorithmes de complexité quadratique sur des entrées qui atteignent facilement une taille non triviale dans les cas d'utilisation courants. Qui fait ça de toute façon? Mais je ne pense même pas que ce soit un gros problème si la mise en œuvre est facile à échanger plus tard. Ce n'est toujours pas une grave erreur si vous n'avez pas à reconsidérer vos conceptions.