Ich bin vielleicht voreingenommen in sehr leistungskritischen Bereichen wie Bildverarbeitung und Raytracing, aber ich würde trotzdem sagen, dass ich "so spät wie möglich" optimieren soll . Unabhängig davon, wie leistungskritisch Ihre Anforderungen sind, gibt es nach der Messung im Nachhinein immer so viel mehr Informationen und Klarheit als im Voraus. Dies bedeutet, dass selbst die effektivsten Optimierungen in der Regel später angewendet werden, nachdem Sie sich ein solches Wissen angeeignet haben.
Besondere Fälle
Aber manchmal ist "so spät wie möglich" in einigen besonderen Fällen immer noch verdammt früh. Wenn es sich beispielsweise um Offline-Renderer handelt, fließen die Datenstrukturen und -techniken, mit denen Sie Leistung erzielen, tatsächlich in das Design für Benutzer ein. Dies mag ekelhaft klingen, aber das Feld ist so aktuell und so leistungskritisch, dass Benutzer benutzerspezifische Steuerelemente akzeptieren, die für die für einen bestimmten Raytracer geltenden Optimierungstechniken (z. B. Caching der Bestrahlungsstärke oder Photonenzuordnung) spezifisch sind, da einige von ihnen verwendet werden Es ist gewohnt, stundenlang auf das Rendern eines Bildes zu warten, und andere sind es gewohnt, enorme Geldsummen für die Miete oder den Besitz einer Renderfarm mit Geräten für das Rendern auszugeben. Für diese Benutzer bedeutet dies eine erhebliche Zeit- und Geldersparnis, wenn ein wettbewerbsfähiger Offline-Renderer eine nicht unerhebliche Reduzierung des Zeitaufwands für das Rendern bieten kann. Dies ist eine Art Bereich, in dem eine Zeitersparnis von 5% die Benutzer tatsächlich begeistert.
In solchen besonderen Fällen können Sie nicht einfach eine Rendering-Technik auswählen und hoffen, diese später zu optimieren, da sich das gesamte Design, einschließlich des benutzerseitigen Designs, auf die von Ihnen verwendeten Datenstrukturen und Algorithmen konzentriert. Sie können nicht unbedingt einfach das tun, was für andere Menschen gut funktioniert hat, da Sie als Einzelperson und Ihre besonderen Stärken und Schwächen entscheidend dazu beitragen, eine wettbewerbsfähige Lösung zu finden. Die Einstellung und Sensibilität des Hauptentwicklers hinter Arnold unterscheidet sich von denen, die an VRay arbeiten und einen ganz anderen Ansatz verfolgen. Sie können nicht unbedingt Orte / Techniken tauschen und den besten Job machen (obwohl sie beide Industrieführer sind). Sie müssen experimentieren, einen Prototyp und einen Benchmark erstellen und herausfinden, was Sie suchen. Es ist besonders gut, wenn man bedenkt, dass es eine endlose Reihe von Spitzentechniken gibt, wenn man hofft, etwas Wettbewerbsfähiges zu liefern, das sich tatsächlich verkaufen wird. In diesem besonderen Fall rücken die Leistungsbedenken als vielleicht wichtigste Bedenken vor Beginn der Entwicklung in den Vordergrund.
Dies ist jedoch nicht unbedingt eine Verletzung der Optimierung von "so spät wie möglich" , sondern "so spät wie möglich" ist in diesen extremen und besonderen Fällen eher früh. Wenn überhaupt, ist es wahrscheinlich die größte Herausforderung für den Entwickler, herauszufinden, wann und was solche frühen Performance-Bedenken nicht benötigt. Was man nicht optimieren sollte, ist möglicherweise eines der wertvollsten Dinge, die man in der Karriere eines Entwicklers lernen und weiter lernen kann, da es nicht an naiven Entwicklern mangelt, die alles optimieren möchten (und leider auch an Veteranen, die es irgendwie geschafft haben, ihren Job zu behalten) trotz ihrer Kontraproduktivität).
So spät wie möglich
Vielleicht ist es am schwierigsten zu verstehen, was es bedeutet. Ich lerne noch und programmiere seit fast drei Jahrzehnten. Aber gerade jetzt in meinem dritten Jahrzehnt beginne ich zu erkennen, dass es nicht so schwierig ist. Es ist keine Hexerei, wenn Sie sich mehr auf Design als auf Implementierung konzentrieren. Je mehr Ihre Entwürfe später ohne Änderungen am Entwurf Freiraum für entsprechende Optimierungen lassen, desto später können Sie optimieren. Und je produktiver ich geworden bin, desto mehr habe ich nach solchen Designs gesucht, die mir den nötigen Freiraum bieten.
Entwerfen Sie, welche Atempause bieten, um später zu optimieren
Diese Arten von Designs sind in den meisten Fällen gar nicht so schwer zu realisieren, wenn wir einen "gesunden Menschenverstand" anwenden können. Als persönliche Geschichte beschäftige ich mich mit bildender Kunst als Hobby (ich finde es etwas hilfreich, Software zu programmieren, damit Künstler ihre Bedürfnisse verstehen und ihre Sprache sprechen können), und ich habe Anfang der 2000er Jahre einige Zeit mit Oekaki-Applets verbracht Online als schnelle Möglichkeit, meine Arbeit zu kritzeln, zu teilen und mit anderen Künstlern in Kontakt zu treten.
Insbesondere meine Lieblings-Site und mein Lieblings-Applet waren mit Leistungsmängeln übersät (jede nicht triviale Pinselgröße würde zu einem Crawl verlangsamen), hatten aber eine sehr nette Community. Um die Performance-Probleme zu umgehen, habe ich kleine 1 oder 2-Pixel-Pinsel verwendet und meine Arbeit einfach so gekritzelt:
In der Zwischenzeit gab ich dem Autor der Software Vorschläge zur Leistungsverbesserung und er bemerkte, dass meine Vorschläge besonders technischer Natur waren und sich mit Speicheroptimierungen und Algorithmen usw. befassten. Also fragte er tatsächlich, ob ich ein Programmierer sei und ich sagte ja und er lud mich ein, am Quellcode zu arbeiten.
Also habe ich mir den Quellcode angesehen, ihn ausgeführt, profiliert und zu meinem Entsetzen die Software nach dem Konzept einer "abstrakten Pixelschnittstelle" entworfen IPixel, die letztendlich die Ursache hinter den Top-Hotspots für alles mit Dynamik war Zuweisungen und Versand für jedes einzelne Pixel jedes einzelnen Bildes. Es gab jedoch keine praktische Möglichkeit, dies zu optimieren, ohne das Design der gesamten Software zu überdenken, da das Design ihn in eine Ecke geführt hatte, in der es kaum etwas Außergewöhnliches gibt, wenn unsere Abstraktionen auf der granularen Ebene eines einzelnen abstrakten Pixels arbeiten und alles hängt von diesem abstrakten Pixel ab.
Ich denke, das ist eine Verletzung des "gesunden Menschenverstandes", aber offensichtlich war es für den Entwickler nicht so vernünftig. Aber es ist so, als ob Sie keine abstrakten Dinge auf solch einer granularen Ebene machen, bei der selbst die grundlegendsten Anwendungsfälle millionenfach instanziiert werden, wie bei Pixeln oder Partikeln oder winzigen Einheiten in einer gigantischen Armeesimulation. Favor die IImage(Sie alle das Bild / Pixelformate , die Sie in dieser sperrigen aggregierter Ebene müssen umgehen können) oder IParticleSysteman IPixeloder IParticle, und dann können Sie in den grundlegendsten setzen und schnell zu schreiben und einfach zu verstehende Implementierungen hinter solchen Schnittstellen und Sie haben den ganzen Freiraum, den Sie später optimieren müssen, ohne das Design der gesamten Software zu überdenken.
Und das ist das Ziel, wie ich es heutzutage sehe. Ausgenommen der besonderen Fälle, wie die oben genannten Offline-Renderer, sollten Sie so viel Freiraum für eine spätestmögliche Optimierung mit möglichst vielen Informationen im Nachhinein (einschließlich Messungen) bereitstellen und die erforderlichen Optimierungen so spät wie möglich durchführen.
Natürlich schlage ich nicht unbedingt vor, mit der Verwendung von Algorithmen mit quadratischer Komplexität für Eingaben zu beginnen, die in allgemeinen Fällen für Benutzer leicht eine nicht triviale Größe erreichen. Wer macht das schon? Aber ich denke nicht, dass das so eine große Sache ist, wenn die Implementierung später einfach ausgetauscht werden kann. Das ist immer noch kein schwerer Fehler, wenn Sie keine Entwürfe überdenken müssen.