Warum ist es so schlimm, zu früh zu optimieren?

168

Nachdem ich ein wenig über Optimierung nachgedacht habe, habe ich (buchstäblich überall) festgestellt, dass es eine allgemein anerkannte Sünde ist, ein Spiel zu früh zu optimieren.

Ich verstehe das wirklich nicht. Wäre es nicht unglaublich schwierig, einige der Kernstrukturen des Spiels am Ende zu ändern, anstatt sie das erste Mal mit Blick auf die Leistung zu entwickeln?

Das Warten bis das Spiel beendet ist, wird Ihnen sagen, ob Sie Optimierungen benötigen, aber sollten Sie es trotzdem nicht tun, könnte es die Vielfalt der Geräte erweitern, auf denen das Spiel laufen könnte, was die Anzahl der potenziellen Geräte erhöhen würde Spieler.

Könnte mir jemand erklären, warum es so eine schlechte Idee ist, zu früh zu optimieren?

Herr-matt
quelle
Kommentare sind nicht für eine längere Diskussion gedacht. Diese Unterhaltung wurde in den Chat verschoben .
Josh
3
Es könnte nicht einfacher sein, dies zu beantworten: "Es verschwendet Zeit". Sie könnten genauso gut fragen: "Warum versuchen Sie beim Einkaufen Geld zu sparen?"
Fattie
27
Beachten Sie umgekehrt, dass viele Ingenieure ganz einfach sagen, dass der Satz "Nicht zu früh optimieren" einfach falsch ist . Der Satz sollte einfach lauten: "Optimiere nicht, bis du weißt, was zu optimieren ist". Wenn es also drei Systeme A, B und C gibt, ist es völlig sinnlos, A zu optimieren, wenn sich herausstellt, dass A in keiner Weise ein Engpass ist und C tatsächlich der Engpass ist. In diesem Beispiel wäre die Optimierung von A natürlich eine reine Zeitverschwendung gewesen. Optimieren Sie also - ganz einfach - erst, wenn Sie wissen, welches von A, BC zu optimieren ist: Das ist alles, was es bedeutet, es ist so einfach.
Fattie
2
Das Optimieren der Zeitklasse Ihrer Anwendung während der Entwicklung unterscheidet sich erheblich von dem Versuch, einige Anweisungen aus einer Schleife zu entfernen, die normalerweise eine konstante Zeit ist. Konzentrieren Sie sich auf O (n) vs O (n log n), anstatt "das Schreiben einer for-Schleife auf diese Weise spart eine CPU-Anweisung".
1
@phyrfox Eigentlich scheint mir die Verkürzung der Ladezeit beeindruckender zu sein. Die Ladezeit von drei Sekunden ist spürbar. Ich bin mir nicht sicher, ob 55fps bis 60fps auffallen.
immibis

Antworten:

237

Präambel:

In den Kommentaren wurden einige Einwände erhoben, und ich denke, sie beruhen größtenteils auf einem Missverständnis dessen, was wir unter "vorzeitiger Optimierung" verstehen - daher wollte ich dies etwas präzisieren.

"Nicht vorzeitig optimieren" bedeutet nicht "Code schreiben, von dem Sie wissen, dass er schlecht ist, weil Knuth sagt, dass Sie ihn nicht bis zum Ende bereinigen dürfen".

Es bedeutet: "Verlieren Sie keine Zeit und Lesbarkeit für die Optimierung, bis Sie wissen, welche Teile Ihres Programms tatsächlich Hilfe benötigen, um schneller zu sein." Da ein typisches Programm die meiste Zeit in ein paar Engpässen verbringt, führt die Investition in die Optimierung von "alles" möglicherweise nicht zu einer Geschwindigkeitssteigerung, die der Konzentration derselben Investition auf nur den Code mit Engpässen gleichkommt.

Dies bedeutet, dass wir im Zweifelsfall :

  • Bevorzugen Sie Code, der einfach zu schreiben, klar zu verstehen und für den Anfang einfach zu ändern ist

  • Überprüfen Sie, ob weitere Optimierungen erforderlich sind (in der Regel durch Erstellen eines Profils für das laufende Programm, obwohl ein Kommentar unter den Hinweisen eine mathematische Analyse enthält - das einzige Risiko besteht darin, dass Sie auch überprüfen müssen, ob Ihre Mathematik richtig ist).

Eine vorzeitige Optimierung ist nicht :

  • Architekturentscheidungen zur bedarfsgerechten Strukturierung Ihres Codes - Auswahl geeigneter Module / Verantwortlichkeiten / Schnittstellen / Kommunikationssysteme mit Bedacht.

  • Einfache Effizienz, die keine zusätzliche Zeit in Anspruch nimmt oder das Lesen Ihres Codes erschwert. Dinge wie das Verwenden von starker Eingabe können sowohl effizient sein als auch Ihre Absicht klarer machen. Ein weiteres Beispiel ist das Zwischenspeichern eines Verweises, anstatt wiederholt danach zu suchen (solange Ihr Fall keine komplexe Logik zur Ungültigmachung des Cache erfordert - vielleicht sollten Sie dies erst schreiben, wenn Sie das Profil auf einfache Weise erstellt haben).

  • Den richtigen Algorithmus für den Job verwenden. Ein * ist optimaler und komplexer als eine erschöpfende Suche in einem Wegfindungsdiagramm. Es ist auch ein Industriestandard. Wenn Sie das Thema wiederholen und sich an bewährte Methoden wie diese halten, wird Ihr Code möglicherweise leichter verständlich, als wenn Sie etwas Einfaches tun, das den bekannten Best Practices widerspricht. Wenn Sie Erfahrung mit Engpässen bei der Implementierung von Spielefeature X in einem früheren Projekt haben, müssen Sie diesen Engpass bei diesem Projekt nicht erneut feststellen, um zu wissen, dass er real ist. Sie können und sollten Lösungen wiederverwenden, die in der Vergangenheit funktioniert haben Spiele.

All diese Optimierungsarten sind gut begründet und werden im Allgemeinen nicht als "vorzeitig" bezeichnet (es sei denn, Sie gehen in ein Kaninchenloch und implementieren die modernste Pfadfindung für Ihre 8x8-Schachbrettkarte ...).

Nachdem dies geklärt ist, erfahren Sie , warum diese Richtlinie für Spiele besonders nützlich sein kann:


Vor allem in Gamedev ist die Iterationsgeschwindigkeit das Kostbarste. Wir werden oft viel mehr Ideen implementieren und erneut implementieren, als letztendlich mit dem fertigen Spiel geliefert werden, und versuchen, "den Spaß zu finden".

Wenn Sie einen Mechaniker auf einfache und vielleicht etwas naive Weise prototypisieren und ihn am nächsten Tag testen können, sind Sie in einer viel besseren Position, als wenn Sie eine Woche damit verbracht hätten, die optimalste Version zuerst zu erstellen. Vor allem, wenn sich herausstellt, dass Sie nichts zu suchen haben und diese Funktion am Ende nicht mehr verwenden. Wenn Sie dies auf einfache Weise tun, um frühzeitig zu testen, können Sie eine Menge verschwendeter Arbeit bei der Optimierung von Code sparen, den Sie nicht behalten.

Nicht optimierter Code ist im Allgemeinen auch einfacher zu modifizieren und verschiedene Varianten auszuprobieren als Code, der fein abgestimmt ist, um eine präzise Sache optimal zu machen. Dieser Code ist in der Regel spröde und schwieriger zu modifizieren, ohne ihn zu beschädigen, Fehler einzuführen oder ihn zu verlangsamen. Wenn der Code einfach und leicht zu ändern ist, ist dies während des größten Teils der Entwicklung oftmals eine geringe Ineffizienz der Laufzeit wert (wir entwickeln normalerweise auf Computern, die über der Zielspezifikation liegen, damit wir den Overhead auffangen und uns darauf konzentrieren können, zuerst die Zielerfahrung zu erzielen) Ich habe das gesperrt, was wir von der Funktion benötigen, und kann die Teile optimieren, von denen wir jetzt wissen, dass sie langsam sind.

Ja, es kann schwierig sein, Teile des Projekts spät in der Entwicklung umzugestalten, um die langsamen Stellen zu optimieren. Dies gilt jedoch auch für das wiederholte Umgestalten während der gesamten Entwicklung, da die Optimierungen, die Sie im letzten Monat vorgenommen haben, nicht mit der Richtung vereinbar sind, in die sich das Spiel seitdem entwickelt hat, oder etwas behoben haben, das sich als nicht der wahre Engpass herausstellte, sobald Sie mehr Features und Inhalte erhalten haben im.

Spiele sind seltsam und experimentell - es ist schwer vorherzusagen, wie sich ein Spielprojekt und seine technischen Anforderungen entwickeln und wo die Leistung am höchsten ist. In der Praxis machen wir uns oft Sorgen über die falschen Dinge - durchsuchen Sie die Fragen zur Leistung hier und Sie werden sehen, dass ein gemeinsames Thema entsteht, bei dem Entwickler von Dingen auf Papier abgelenkt werden, die wahrscheinlich überhaupt kein Problem darstellen.

Um ein dramatisches Beispiel zu nennen: Wenn Ihr Spiel an eine GPU gebunden ist (nicht ungewöhnlich), wird die gesamte Zeit, die Sie für die Optimierung und das Threading der CPU-Arbeit aufgewendet haben, möglicherweise keinen greifbaren Nutzen bringen. All diese Entwicklerstunden hätten dafür verwendet werden können, Gameplay-Funktionen zu implementieren und zu verbessern, um eine bessere Spielerfahrung zu erzielen.

Insgesamt wird die meiste Zeit, die Sie mit der Arbeit an einem Spiel verbringen, nicht für den Code aufgewendet, der letztendlich zum Engpass wird. Vor allem, wenn Sie an einer vorhandenen Engine arbeiten, können Sie die extrem teuren internen Regelkreise in den Rendering- und Physiksystemen nicht mehr verwenden. Zu diesem Zeitpunkt besteht Ihre Aufgabe in den Gameplay-Skripten darin, der Engine im Grunde genommen aus dem Weg zu gehen. Solange Sie dort keinen Schraubenschlüssel hineinwerfen, werden Sie bei einem ersten Build wahrscheinlich ganz gut abschneiden.

Abgesehen von ein bisschen Code-Hygiene und Budgetierung (z. B. Suchen Sie nicht wiederholt nach Dingen / Konstruieren, wenn Sie sie leicht wiederverwenden können, halten Sie Ihre Pathfinding- / Physik-Abfragen oder GPU-Rücklesevorgänge bescheiden usw.) und machen Sie sich zur Gewohnheit, nicht vorbei zu sein - Die Optimierung, bevor wir wissen, wo die tatsächlichen Probleme auftreten, wirkt sich positiv auf die Produktivität aus. So sparen wir uns Zeit, die falschen Dinge zu optimieren, und halten unseren Code insgesamt einfacher und einfacher zu optimieren.

DMGregory
quelle
38
Hier wird noch etwas über StackOverflow diskutiert , wobei die Bedeutung von Lesbarkeit und Klarheit im Code sowie die Gefahr hervorgehoben werden, dass Code durch vorzeitige Optimierung schwerer zu verstehen ist (und leichter in Fehler einzuführen ist).
DMGregory
8
Eine großartige Antwort, möchte ich hinzufügen, als Antwort auf " Wäre es nicht unglaublich schwierig, einige der Kernstrukturen des Spiels am Ende zu ändern, anstatt sie das erste Mal mit Blick auf die Leistung zu entwickeln? " Natürlich versuchen Sie, in erster Linie auf Effizienz zu achten. Wenn Sie zwei Möglichkeiten haben, wählen Sie die effizientere. Andernfalls schreiben Sie das Spiel so modular wie möglich mit gut definierten Schnittstellen. Sie können dann die Mechanismen in jedem Modul ändern, ohne die gesamte Codebasis neu zu strukturieren.
Baldrickk
1
@Baldrickk Ich würde sagen, dass es sich lohnt, dies als zusätzliche Antwort mitzuteilen. (Ich würde es positiv bewerten!) In meiner Antwort überspringe ich die Bedeutung von Architektur und Planung, um zu vermeiden, dass große Probleme entstehen. In Bezug auf Gizmos Hinweis auf "Programmentwicklung im Allgemeinen" kommt dieses Konzept der vorzeitigen Optimierung daher. Wie oben ausgeführt, kann die falsche Optimierung ebenso leicht zu einer technischen Verschuldung werden wie eine fehlende Optimierung. Wir sollten jedoch betonen, dass wir die Dinge niemals absichtlich langsam
angehen
1
Auch wenn ich hier von Euch wahrscheinlich am unerfahrensten bin, muss ich sagen, dass ich diese "vorzeitige Optimierungswurzel allen Übels" etwas seltsam finde. Vor ungefähr zwei Jahren habe ich versucht, etwas in Unity3D zu tun. Ich habe ein paar LINQ-Abfragen geschrieben, wobei jede die vorherige verwendete. Ich schaute auf meinen Code und bekam starke Zweifel. Ich fand die Komplexität der Berechnung schrecklich. Ich nahm ein Blatt Papier und rechnete damit, dass die Bearbeitung dieser Abfragen mit einer erwarteten Datenmenge Stunden dauern würde. Also habe ich hier und da ein wenig Caching hinzugefügt. Und die Abfragen liefen gut.
Gaazkam
3
Sie haben die Due Diligence-Prüfung durchgeführt und überprüft, ob das Problem tatsächlich aufgetreten ist, bevor Sie den Code von dem geändert haben, was anfangs für Sie am klarsten und intuitivsten war. Das bedeutet, dass Ihre Optimierung nicht verfrüht war. ;) "Überoptimierung vorzeitig vermeiden" bedeutet nicht "unnötig teuren Code schreiben" - nur um die Einfachheit, Lesbarkeit und Modifizierbarkeit zu verbessern, bis ein bestimmtes Leistungsproblem erkannt wurde. Die Kommentare sind nicht für Diskussionen vorgesehen, daher können wir mit Ihnen chatten, wenn Sie darüber weiter sprechen möchten.
DMGregory
42

Anmerkung: Diese Antwort begann als Kommentar zu DMGregorys Antwort und dupliziert daher nicht die sehr guten Punkte, die er macht.

"Wäre es nicht unglaublich schwierig, einige der Kernstrukturen des Spiels am Ende zu ändern, anstatt sie beim ersten Mal mit Blick auf die Leistung zu entwickeln?"

Dies ist für mich der Kern der Frage.

Wenn Sie Ihr ursprüngliches Design erstellen, sollten Sie versuchen, auf höchstem Niveau effizient zu gestalten. Dies ist weniger eine Optimierung, und es geht mehr um Struktur.

Beispiel:
Sie müssen ein System erstellen, um einen Fluss zu überqueren. Die naheliegenden Entwürfe sind eine Brücke oder eine Fähre. Welche wählen Sie?
Die Antwort hängt natürlich von der Größe der Überfahrt und dem Verkehrsaufkommen ab. Dies ist keine Optimierung, sondern beginnt mit einem Design, das für Ihr Problem geeignet ist.

Wenn Sie eine Auswahl an Designs treffen, wählen Sie diejenige aus, die am besten zu Ihren Vorstellungen passt.

Nehmen wir also an, dass unser Verkehrsaufkommen relativ gering ist, und beschließen, zwei Terminals zu bauen und eine Fähre zu kaufen, um den Verkehr zu bewältigen. Eine nette einfache Implementierung
Leider stellen wir fest, dass nach dem Start mehr Verkehr als erwartet zu verzeichnen ist. Wir müssen die Fähre optimieren! (weil es funktioniert und der Bau einer Brücke jetzt kein guter Plan ist)

Optionen:

  • Kaufen Sie eine zweite Fähre (Parallelverarbeitung)
  • Hinzufügen eines weiteren Autodecks zur Fähre (Verdichtung des Verkehrs)
  • Rüste den Motor der Fähre auf, um ihn schneller zu machen (überarbeitete Verarbeitungsalgorithmen)

Hier sollten Sie versuchen, Ihr ursprüngliches Design so modular wie möglich zu gestalten.
Alle oben genannten sind mögliche Optimierungen, und Sie könnten sogar alle drei tun.
Aber wie können Sie diese Änderungen ohne große strukturelle Änderungen vornehmen?

Wenn Sie modular aufgebaut sind und klar definierte Schnittstellen haben, sollten sich diese Änderungen leicht umsetzen lassen.
Wenn Ihr Code nicht eng gekoppelt ist, wirken sich Änderungen an Modulen nicht auf die umgebende Struktur aus.

Werfen wir einen Blick auf das Hinzufügen einer zusätzlichen Fähre.
Ein "schlechtes" Programm könnte auf der Idee einer einzelnen Fähre aufbauen und die Dockzustände und den Fährstatus und die Position zusammenfassen und den Status gemeinsam nutzen. Dies kann nur schwer geändert werden, damit dem System eine zusätzliche Fähre hinzugefügt werden kann.
Ein besseres Design wäre, die Docks und die Fähre als separate Einheiten zu haben. Es gibt keine enge Verbindung zwischen ihnen, aber sie haben eine Schnittstelle, an der eine Fähre ankommen, Passagiere entladen, neue übernehmen und abfahren kann. Das Dock und die Fähre teilen sich nur diese Schnittstelle, und dies macht es einfach, Änderungen am System vorzunehmen, in diesem Fall durch Hinzufügen einer zweiten Fähre. Das Dock kümmert sich nicht darum, welche Fähren es tatsächlich gibt, es geht nur darum, dass etwas (irgendetwas) seine Schnittstelle verwendet.

tl; dr:

  • Versuchen Sie zunächst, auf Effizienz zu achten.
  • Wenn Sie zwei Möglichkeiten haben, wählen Sie die effizientere.
  • Schreiben Sie Ihren Code so modular wie möglich mit gut definierten Schnittstellen.

Sie können dann die Mechanismen in jedem Modul ändern, ohne die gesamte Codebasis neu zu strukturieren, wenn Sie eine Optimierung benötigen.

Baldrickk
quelle
16
Zu Beginn können Sie Ihre Fähre auch als implementieren. IRiverCrossingWenn sich herausstellt, dass das Verkehrsaufkommen für die eingerichtete Fähre zu groß ist, implementieren Sie die Brücke als IRiverCrossingund legen Sie sie ab. Der Trick besteht natürlich darin, die externe API der Fähre zu reduzieren und die Brücke zu gemeinsamen Funktionen, damit sie von derselben Schnittstelle dargestellt werden können.
Mr. Mindor
2
Möglicherweise haben Sie sogar automatisierte Tests für diese modularen Schnittstellen geschrieben, sodass Sie schnell umgestalten können, ohne sich große Sorgen machen zu müssen, dass etwas außerhalb des Moduls, das Sie berühren, beschädigt wird.
user3067860
2
Sehr schönes Beispiel, warum OOP heutzutage so wichtig ist.
Jaime Gallego
1
Sie haben den richtigen Grund getroffen. Donald Knuths Mantra ist nur dann richtig, wenn Geschwindigkeit nicht zu den Kernanforderungen zählt und ein Fokus auf Optimierung das Hauptdesign gefährden würde. Ach, in den Spielen beschleunigen oft ist in den Mittelpunkt, und damit müssen frühzeitig in die Gestaltung einbezogen werden. Die Besorgnis des OP (und Ihre Antwort) ist völlig gerechtfertigt.
Peter A. Schneider
3
@AlexandreVaillancourt Anstatt den Titel der Frage zu beantworten, habe ich versucht zu beantworten, was meiner Meinung nach der Schlüssel zur Beantwortung der Frage ist. Das heißt, "warum sollte ich nicht früh optimieren, wenn das Optimieren später viel mehr Arbeit bedeutet, weil mein Design festgelegt ist" (umschrieben) . Diese Antwort begann auch als Kommentar zu DMGregorys Antwort und ist eine Ergänzung dazu, und es macht nicht viel Sinn, seine Antwort zu duplizieren.
Baldrickk
24

"Nicht zu früh optimieren" bedeutet nicht "die schlechteste Methode wählen, um Dinge zu tun". Sie müssen immer noch die Auswirkungen auf die Leistung berücksichtigen (es sei denn, Sie erstellen nur Prototypen). Es geht nicht darum, andere, wichtigere Dinge zu diesem Zeitpunkt in der Entwicklung zu lähmen - wie Flexibilität, Zuverlässigkeit usw. Wählen Sie einfache, sichere Optimierungen - wählen Sie die Dinge aus, die Sie einschränken und die Dinge, die Sie freihalten. Behalten Sie die Kosten im Auge. Solltest du stark tippen? Die meisten Spiele haben gut funktioniert. Wie viel würde es Sie kosten, das zu entfernen, wenn Sie interessante Anwendungen der Flexibilität für das Gamemplay finden würden?

Es ist viel schwieriger, optimierten Code zu ändern, insbesondere "intelligenten" Code. Es ist immer eine Entscheidung, die einige Dinge verbessert und andere verschlechtert (zum Beispiel, wenn Sie CPU-Zeit für die Speichernutzung eintauschen). Wenn Sie diese Wahl treffen, müssen Sie sich aller Auswirkungen bewusst sein - sie können katastrophal sein, aber sie können auch hilfreich sein.

Zum Beispiel wurden Commander Keen, Wolfenstein und Doom jeweils auf einer optimierten Rendering-Engine aufgebaut. Jeder hatte seinen "Trick", der es überhaupt erst ermöglichte, dass das Spiel existierte (jeder hatte im Laufe der Zeit weitere Optimierungen entwickelt, aber das ist hier nicht wichtig). Das ist in Ordnung . Es ist in Ordnung, den Kern des Spiels stark zu optimieren, das Denken, das das Spiel ermöglicht; Vor allem, wenn Sie Neuland erkunden, in dem diese optimierte Funktion es Ihnen ermöglicht, Spieldesigns zu berücksichtigen, die nicht viel erforscht wurden. Die durch die Optimierung eingeführten Einschränkungen können Ihnen auch ein interessantes Spielvergnügen bringen (z. B. haben die Begrenzungen der Einheitenzahl in RTS-Spielen möglicherweise begonnen, um die Leistung zu verbessern, sie haben jedoch auch einen Gameplay-Effekt).

Beachten Sie jedoch, dass in jedem dieser Beispiele das Spiel ohne die Optimierung nicht existieren könnte. Sie starteten nicht mit einem "voll optimierten" Motor - sie starteten mit dem Nötigsten und arbeiteten sich nach oben. Sie entwickelten neue Technologien und verwendeten sie, um lustige Spiele zu machen. Und die Engine-Tricks beschränkten sich auf einen möglichst kleinen Teil der Codebasis - die stärkeren Optimierungen wurden erst eingeführt, als das Gameplay größtenteils fertig war oder ein interessantes neues Feature auftauchte.

Nun überlegen Sie sich ein Spiel, das Sie vielleicht machen möchten. Gibt es wirklich ein technologisches Wunder, das dieses Spiel macht oder bricht? Vielleicht stellen Sie sich ein Open-World-Spiel in einer unendlichen Welt vor. Ist das wirklich das zentrale Stück des Spiels? Wäre das Spiel ohne nicht möglich? Vielleicht denkst du an ein Spiel, bei dem das Terrain unbegrenzt deformierbar ist, mit realistischer Geologie und so weiter. können Sie es mit einem kleineren Umfang arbeiten lassen? Würde es in 2D statt in 3D funktionieren? Holen Sie sich so schnell wie möglich etwas, das Spaß macht - auch wenn Sie bei Optimierungen möglicherweise einen großen Teil Ihres vorhandenen Codes überarbeiten müssen, kann es sich lohnen. und vielleicht merkt man sogar, dass das Spiel nicht wirklich besser wird, wenn man Dinge größer macht.

Als Beispiel für ein aktuelles Spiel mit vielen Optimierungen würde ich auf Factorio verweisen. Ein entscheidender Teil des Spiels sind die Gürtel - es gibt viele Tausende von ihnen und sie tragen viele einzelne Materialteile in Ihrer gesamten Fabrik. Hat das Spiel mit einer stark optimierten Riemenmaschine begonnen? Nein! Tatsächlich war es fast unmöglich, das ursprüngliche Gürteldesign zu optimieren - es wurde eine Art physikalische Simulation der Gegenstände auf dem Gürtel durchgeführt, die einige interessante Dinge hervorbrachte, die Sie tun konnten (auf diese Weise erhalten Sie ein "aufstrebendes" Gameplay - ein Gameplay, das überrascht der Designer), aber bedeutete, dass Sie jedes einzelne Element auf dem Gürtel simulieren mussten. Mit Tausenden von Bändern erhalten Sie Zehntausende von physisch simulierten Objekten - selbst wenn Sie diese entfernen und die Bänder die Arbeit erledigen lassen, können Sie die zugehörige CPU-Zeit um 95-99% verkürzen. auch ohne Berücksichtigung von Dingen wie der Speicherlokalität. Dies ist jedoch nur dann sinnvoll, wenn Sie tatsächlich an diese Grenzen stoßen.

Fast alles, was mit Riemen zu tun hatte, musste neu hergestellt werden, damit die Riemen optimiert werden konnten. Und die Bänder mussten optimiert werden, da für eine große Fabrik viele Bänder benötigt wurden und große Fabriken eine Attraktion des Spiels sind. Wenn Sie keine großen Fabriken haben können, warum dann eine unendliche Welt? Witzig, sollte man fragen - frühe Versionen haben das nicht getan :) Das Spiel wurde viele Male überarbeitet und umgestaltet, um zu sehen, wo es jetzt ist Spiel wie dieses und wechselte zu C ++. Und für Factorio hat es super geklappt (obwohl es immer noch gut war, dass es von Anfang an nicht optimiert wurde - zumal es sich um ein Hobbyprojekt handelte, das ansonsten aus Mangel an Interesse einfach gescheitert wäre).

Aber die Sache ist, es gibtViele Dinge, die Sie mit einer Fabrik mit begrenztem Umfang tun können - und viele Spiele haben genau das gezeigt. Grenzen können zum Spaß noch stärker sein als Freiheiten; würde Spacechem mehr Spaß machen, wenn die "Karten" unendlich wären? Wenn Sie mit stark optimierten "Gürteln" anfangen würden, wären Sie so ziemlich gezwungen, diesen Weg zu gehen. und man konnte keine anderen Konstruktionsrichtungen erkunden (wie zum Beispiel zu sehen, welche interessanten Dinge man mit physikalisch simulierten Förderbändern machen kann). Sie begrenzen Ihren potenziellen Gestaltungsspielraum. Es mag nicht so aussehen, weil Sie nicht viele unvollendete Spiele sehen, aber der schwierige Teil ist, den Spaß richtig zu machen - für jedes lustige Spiel, das Sie sehen, gibt es wahrscheinlich Hunderte, die einfach nicht dorthin gelangen konnten und verschrottet wurden (oder schlimmer, als schreckliches Durcheinander veröffentlicht). Wenn Ihnen die Optimierung dabei hilft, fahren Sie fort. Wenn es nicht ... Es ist wahrscheinlich verfrüht. Wenn Sie der Meinung sind, dass einige Gameplay-Mechaniken großartig funktionieren, aber Optimierungen benötigen, um wirklich zu glänzen, dann machen Sie weiter. Wenn Sie nicht interessante Mechanik haben,optimiere sie nicht . Finden Sie zuerst den Spaß - Sie werden feststellen, dass die meisten Optimierungen dabei nicht helfen und oft schädlich sind.

Endlich hast du ein tolles, lustiges Spiel. Ist es sinnvoll, jetzt zu optimieren ? Ha! Es ist immer noch nicht so klar, wie Sie vielleicht denken. Gibt es etwas, das Spaß macht?können Sie stattdessen tun? Vergiss nicht, dass deine Zeit immer noch begrenzt ist. Alles ist anstrengend, und Sie möchten sich darauf konzentrieren, wo es am wichtigsten ist. Ja, auch wenn Sie ein "freies Spiel" oder ein "Open Source" -Spiel machen. Beobachten Sie, wie das Spiel gespielt wird. bemerken, wo die Leistung zu einem Engpass wird. Macht die Optimierung dieser Orte mehr Spaß (wie das Bauen immer größerer, immer verwickelterer Fabriken)? Ermöglicht es Ihnen, mehr Spieler anzuziehen (z. B. mit schwächeren Computern oder auf verschiedenen Plattformen)? Sie müssen immer Prioritäten setzen - achten Sie auf das Verhältnis von Aufwand zu Ertrag. Sie werden wahrscheinlich viele niedrig hängende Früchte finden, wenn Sie Ihr Spiel spielen und anderen beim Spielen zuschauen. Beachten Sie jedoch den wichtigen Teil - um dorthin zu gelangen, benötigen Sie ein Spiel . Konzentriere dich darauf.

Bedenken Sie als Krönung, dass die Optimierung niemals endet. Es ist keine Aufgabe mit einem kleinen Häkchen, die Sie abschließen und mit anderen Aufgaben fortfahren. Es gibt immer noch "eine weitere Optimierung", und ein großer Teil jeder Entwicklung besteht darin, die Prioritäten zu verstehen. Sie optimieren nicht um der Optimierung willen, sondern um ein bestimmtes Ziel zu erreichen (z. B. "200 Einheiten gleichzeitig auf dem Bildschirm auf einem 333-MHz-Pentium" ist ein großartiges Ziel). Verliere nicht den Überblick über das Endziel, nur weil du dich zu sehr auf die Zwischenziele konzentrierst, die möglicherweise nicht einmal mehr Voraussetzungen für das Endziel sind.

Luaan
quelle
Ich glaube, die factorio-Entwickler optimieren jetzt die Bänder erneut, sodass sie nur noch Elemente in regelmäßigen Abständen simulieren müssen. In allen anderen Fällen wird nur ihre Position interpoliert, wenn Sie sie betrachten. Aber sie tun das erst jetzt, wenn das gesamte Spiel lange Zeit effektiv auf Gürteln (und Robotern) basiert hat und erst, wenn die Leute anfingen, die Leistung zu bemerken und sich über sie zu beschweren.
immibis
2
@immibis Genau. Eine bessere Leistung, bevor die Menschen tatsächlich an die Grenzen stoßen, wäre eine Verschwendung von Ressourcen, die besser an anderer Stelle eingesetzt werden. Selbst mit den neuesten Optimierungen tritt das Problem höchstwahrscheinlich nur bei den Megafabriken auf, die weit über das normale Gameplay (Starten der Rakete) hinausgehen. Aber es ermöglichte die neuen Marathon-Gameplay-Einstellungen, die eine weitaus schwerere Logistik erfordern. Und wieder identifizierten sie die Engpässe, indem sie Statistiken von Spielern abriefen - etwa die Hälfte der Engpässe war eine große Überraschung für sie.
Luaan
@Fattie Du verstehst also die Frage, aber nicht die Antwort? Wollen Sie nur sagen, dass eine einfachere Antwort möglich ist (zB "Wirtschaft")? Ich verstehe nicht, wie Ihr Kommentar konstruktiv sein soll.
Luaan
2
@Fattie Wenn Sie der Meinung sind, dass die Antwort "Nur optimieren, wenn Sie wissen, was der Engpass ist" ist, posten Sie sie als Antwort. Sie haben bereits viel mehr Wörter ausgegeben, als für eine gute Antwort erforderlich wären. Welche Art von Optimierung macht die Dinge nicht besser und schlechter? Ich habe bestimmt noch nie einen gesehen. Das Grundlegende, worauf ich immer wieder hinweise, ist, dass es immer ein Kompromiss ist - Zeit, die besser woanders verbracht werden könnte, Komplexität, die Ihre Flexibilität einschränkt ... Die Beispiele weisen darauf hin, dass "früh" kein absoluter Begriff ist; Einige Optimierungen sind vom ersten Tag an notwendig, während andere schädlich sind.
Luaan
1
@Fattie "Nur optimieren, wenn Sie wissen, was der Engpass ist" lautet die Antwort auf "Wann sollte ich optimieren?" und ist keine Antwort auf "Warum ist es so schlimm, zu früh zu optimieren?".
immibis
10

Viele der Antworten scheinen sich stark auf den Leistungsaspekt der "Optimierung" zu konzentrieren, während ich mich selbst gerne mit der Optimierung und der ganzen Qual der zu frühen Optimierung auf einer abstrakteren Ebene beschäftige.

Humor mich, wie ich versuche, meine Perspektive mit Hilfe von Polyominoes auszuarbeiten.

Angenommen, wir haben durch das Framework oder die Engine, mit denen wir arbeiten, einige feste Grenzen gesetzt.

Bildbeschreibung hier eingeben

Dann erstellen wir wie folgt unsere erste Ebene / unser erstes Modul des Spiels.

Bildbeschreibung hier eingeben

Im weiteren Verlauf bauen wir unsere zweite Ebene / Modul auf.

Bildbeschreibung hier eingeben

An diesem Punkt stellen wir möglicherweise fest, dass zwischen den beiden Modulen etwas Platz vorhanden ist, und wir sind möglicherweise versucht, ihn zu optimieren, um die uns zugewiesenen Grenzen voll auszunutzen.

Bildbeschreibung hier eingeben

Perfekt, jetzt nutzt die Anwendung die uns zur Verfügung stehenden Ressourcen voll aus. Die Anwendung ist besser, oder?

Wir bauen die dritte Schicht / das dritte Modul unserer Anwendung auf und stellen plötzlich fest (vielleicht sogar eine, die wir bei der anfänglichen Planung nicht vorausgesehen haben), dass die dritte Schicht / das dritte Modul für uns nicht funktioniert.

Wir suchen nach einer Alternative, wir finden eine, und letztendlich müssen wir auch das 2. Modul unserer Anwendung ändern, da es nicht mit unserem neu ausgewählten 3. Modul kompatibel ist. (Zum Glück ist es einigermaßen kompatibel mit unserem ersten Modul, sodass wir nicht alles von Grund auf neu schreiben müssen.)

Also fügten wir alles zusammen ...

Bildbeschreibung hier eingeben

Hmm, kannst du sehen, was passiert ist?

Durch eine zu frühe Optimierung haben wir die Effizienz jetzt tatsächlich verschlechtert, da wir uns nicht mehr für die Optimierung entschieden haben.

Und wenn wir später einige zusätzliche Module oder zusätzliche Leckerbissen hinzufügen wollten, sind wir möglicherweise nicht mehr in der Lage, diese zu tun.

Bildbeschreibung hier eingeben

Und die niedrigste Stufe unseres Systems einzustellen ist nicht mehr so ​​einfach, da es unter allen anderen Schichten verborgen ist.

Wenn wir uns jedoch entschlossen hätten, mit dem Drang zu warten, es sofort zu optimieren, wären wir zu so etwas gekommen:

Bildbeschreibung hier eingeben

Und jetzt, wenn wir die Optimierung an diesem Punkt durchführen, bekommen wir etwas Befriedigendes zum Anschauen.

Bildbeschreibung hier eingeben

Hoffentlich hatten zumindest einige von Ihnen so viel Spaß beim Lesen wie ich beim Erstellen :) und wenn Sie jetzt das Gefühl haben, dass Sie das Thema besser verstehen - umso besser.

Deckengecko
quelle
3
Ich entferne die Werbung. Es ist uns egal, wie Sie die Bilder gemacht haben. Der einzig wichtige Teil ist die Annahme, dass Sie das Recht haben, sie zu posten.
Gnemlock
2
@Gnemlock Fair genug, obwohl meine Absicht nicht auf Werbung abzielte, kann ich auch sehen, wie leicht es als solches fehlinterpretiert werden kann, und ich stimme zu, dass es der Antwort nichts hinzufügt, so dass es keinen Platz darin hat.
Deckengecko
2
Ich halte diese visuelle Metapher für äußerst effektiv. Toller Ansatz zur Beantwortung der Frage! :)
DMGregory
8

Geld.

Darauf kommt es an. Geld. Da Zeit Geld ist *, desto mehr Zeit verbringen Sie mit Aktivitäten, bei denen nicht garantiert ist, dass sie mehr Geld generieren (dh Sie können diese Aktivitäten nicht als Investitionen betrachten ), desto mehr Geld riskieren Sie zu verschwenden und desto weniger Geld verdienen Sie das Spiel.

Hier sind einige weitere mögliche Nebenwirkungen einer zu frühen Optimierung und Gründe, warum Sie diese vermeiden sollten:

  • Ihre Kollegen hassen Sie, weil Sie mit Ihren Spielsachen in Ihrer Sandkiste spielen, während sie hart daran arbeiten, neue Funktionen zu entwickeln.
  • Die Verzögerungen stören das höhere Management und führen dazu, dass das Team Liefertermine verpasst, was dazu führt, dass das Spiel im Frühjahr anstatt vor der Ferienzeit veröffentlicht wird, was wiederum dazu führt, dass das Spiel nicht genug verkauft wird. Aus diesem Grund beschließt die Zentrale, das Studio zu schließen, wodurch Sie praktisch arbeitslos werden. Und kein Job bedeutet kein Geld. (Und da Sie niemand mag, weil Sie zu viel Zeit für die frühe Optimierung aufgewendet haben, möchte niemand auf LinkedIn eine positive Bewertung Ihrer Arbeit für Sie verfassen, die Sie für längere Zeit vom Geld abhält.)

* Andere Antworten haben den 'Zeit'-Teil gut genug hervorgehoben


Als Randnotiz hilft im Allgemeinen die Erfahrung dabei, festzustellen, was eine vorzeitige Optimierung ist und was nicht und was für das Unternehmen von Wert ist und was nicht.

Wenn Sie beispielsweise an Spiel A gearbeitet haben und am Ende des Projekts festgestellt haben, dass die Funktion XYZ Ihre Spielrunde besonders stark belastet, beginnen Sie schließlich mit der Arbeit an Spiel B, das genau die gleiche Funktion hat Das Feature neu zu schreiben und es von Anfang an zu optimieren ist keine vorzeitige Optimierung, da Sie wissen , dass es ein Engpass sein wird, wenn nichts unternommen wird.

Alexandre Vaillancourt
quelle
1
@JBentley das ist ein gültiger Punkt. Es gibt jedoch eine konsequente Antwort auf das "Warum" als direkte Implikation der gesammelten Erfahrung. So, 1) Optimierung frühzeitig zu verschwendete Zeit auf Teile des Codes führen , dass die Erfahrung nicht die durchschnittliche Laufzeit auswirken (gegeben, sollten Sie wissen , welche Code - Konstrukte sind Kandidaten für die Optimierung Best Practices) 2) früh Optimierung kann den Code erschweren zu pflegen aufgrund der konstruktiven Einschränkungen, die über ein System auferlegt sind. Im Gegenzug für längere Entwicklungszyklen oder umständlichen Code, den Sie warten müssen, erhalten Sie möglicherweise zu wenig.
Teodron
3
@JBentley Betrachten Sie dies als Ergänzung zu DMGregorys Antwort.
Alexandre Vaillancourt
1
Dies scheint hier die einzig sinnvolle Antwort zu sein. Die Frage ist eine Tautologie. Sie könnten genauso gut fragen: "Warum möchten Sie eigentlich, dass ein Spiel mehr als weniger Geld in den App-Stores verdient?" Wie kannst du das beantworten?
Fattie
@Fattie Es ist gut, eine solche Perspektive in einer Antwort zu haben. Aber zu sagen, dass es die einzig sinnvolle Antwort ist, schränkt den Umfang der Frage unangemessen ein. Sie nehmen zum Beispiel an, dass die einzigen Spiele von gewinnorientierten Organisationen stammen (eindeutig nicht wahr). Sie gehen auch davon aus, dass es für das OP offensichtlich ist, dass eine frühzeitige Optimierung dazu führt, dass mehr Zeit aufgewendet wird (und damit mehr Geld, wenn es sich um ein Unternehmen handelt). Tatsächlich zeigt die Frage des OP, dass er sich darüber nicht sicher ist.
JBentley
6

Optimierung ist per definitionem der Prozess der Steigerung der Effizienz einer Lösung bis zu dem Punkt, an dem sie ihre Wirksamkeit verliert. Dieser Vorgang impliziert dann eine Verringerung des Raums der Lösung.

In einem frühen Stadium der Softwareentwicklung kann es immer noch zu "versteckten Anforderungen" kommen: Wenn Sie den Speicherplatz Ihrer Lösung zu stark reduzieren, können Sie möglicherweise in eine Situation geraten, in der Sie eine "versteckte Anforderung" beim Auftauchen nicht erfüllen können In einem späteren Stadium der Entwicklung müssen Sie dann die Architektur ändern und auf diese Weise Instabilität und möglicherweise eine Reihe von unerwünschten Verhaltensweisen hinzufügen.

Die Idee ist dann, die gesamte Lösung zum Laufen zu bringen und erst dann, wenn alle Anforderungen festgelegt und implementiert sind, den Code zu verschärfen. Sie werden dann feststellen, dass viele Optimierungen, die Sie beim Codieren mit Leichtigkeit auf einmal vorgenommen hätten, aufgrund der Interaktion mit späten Anforderungen nicht mehr möglich sind.

Der reale Raum der Lösung ist immer größer als derjenige, den wir zu Beginn erwarten, weil wir keine perfekte Kenntnis eines sehr komplexen Systems haben können.

Lass es zuerst funktionieren. Dann die Seile festziehen.

Earendel
quelle
2
Ich denke, "Wirksamkeit" ist nicht das Wort, nach dem Sie suchen - es bedeutet "die Kraft, einen Effekt hervorzurufen". In gewissem Sinne dreht sich bei der Optimierung alles um die Steigerung der Wirksamkeit. Streben Sie eine bestimmte Version der Wirksamkeit an? (Könnten Sie darauf verlinken?) Bedeuten Sie stattdessen so etwas wie Flexibilität?
Doppelgreener
2
@doppelgreener Das bedeutet, dass Sie die Lösung effizienter machen, bis sie nicht mehr die gewünschten Effekte erzeugt ...
immibis
1
"Lass es zuerst funktionieren. Dann zieh die Seile fest." - Das muss genauso viel wert sein wie der Rest der Antwort zusammen. Und um nicht zu sagen, das andere Zeug war nicht gut.
Ebyrob
1
@ebyrob: es gibt einen anderen Spruch: „Machen Sie es funktioniert, es richtig machen, machen es schnell“ wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
ninjalj
@ninjalj Das ist auch gut. Natürlich sagt mir mein Chef immer: "Beeil dich nicht, mach es richtig." Ich weiß also nicht, ob das, was Sie sagen, so universell ist, wie der Auftraggeber, über den das Originalplakat mehr Details verlangt.
Ebyrob
2

Kurz gesagt, wenn Sie später Änderungen vornehmen möchten, wird das frühzeitige Optimieren häufig zu einem Aufwand, und dann haben Sie die leicht zu ändernden Codestrukturen auf eine viel niedrigere Ebene optimiert, und Sie müssen sie jetzt wieder auf eine hohe Ebene zurücksetzen Level-Ansatz, und optimieren Sie das Ergebnis noch einmal.

Dies ist ein häufiger Fehler für Anfänger, die sich darauf konzentrieren möchten, Freude an "nützlicher Arbeit" zu haben, z. B. Optimierung, und nicht darüber nachdenken, ob es der richtige Zeitpunkt ist, dies zu tun. Wenn Sie Erfahrung mit dem Programmieren von großen Projekten wie Spielen sammeln, erfahren Sie, wann eine Optimierung der vorhandenen Codebasis erforderlich ist und wann es zu früh ist. Haben Sie keine Angst, diesen Fehler zu begehen, Sie werden nur davon profitieren, wenn Sie daraus lernen.

Optimieren Sie im Allgemeinen nur, wenn Sie in diesem Moment wirklich nicht mit dem Entwicklungsbuild arbeiten können. Zum Beispiel, wenn Sie 60 Mal pro Sekunde Millionen von Objekten erstellen und löschen.

Daher würde ich sagen, dass es in Bezug auf die Lernerfahrung gut ist, einige Male frühzeitig zu optimieren: p

user1306322
quelle
2

Die Optimierung konzentriert sich darauf, dass der Computer am besten mit dem Code funktioniert, während die Entwicklung erfordert, dass der Programmierer am besten mit dem Code arbeitet.

Optimierung bringt keine Erkenntnisse. Dadurch arbeitet der Computer weniger und der Programmierer mehr.

Natürlich gibt es verschiedene Kategorien, wie beim Entwerfen eines Autos. An der Optimierung eines Motors vor dem Bau Ihres ersten Chassis ist nichts auszusetzen. Die Optimierung des Chassis, bevor Sie die Form des Motors nicht kennen, kann jedoch zu Zeitverschwendung führen. Durch Modularität und Spezifikationen können zahlreiche Stellen für Optimierungsarbeiten bereitgestellt werden, noch bevor das gesamte Produkt zusammengebaut wird.

user101307
quelle
Dies würde verbessert, indem man mit etwas anderem als der Definition von Optimierung führt und über die praktische Situation in der Spieleentwicklung spricht, anstatt Analogien über Autos anzustreben.
doppelgreener
Eine perfekte Antwort auf eine tautologische Frage.
Fattie
2

Ich bin mit all diesen Aussagen nicht einverstanden, dass Code in einem frühen Stadium nicht optimiert werden sollte. Es kommt darauf an, auf welcher Bühne du bist. Wenn dies ein MVP - Prototyp ist und Sie nur versuchen, sich das Spiel anzusehen, das 1 bis 2 Wochen dauert, dann sind Sie bereit, alles, was Sie bereits geschrieben haben, neu zu schreiben. Ja, Optimierung spielt keine Rolle. Wenn Sie jedoch bereits an einem Spiel arbeiten, von dem Sie wissen, dass es veröffentlicht wird, sollte es die ganze Zeit über optimierten Code enthalten. Die Geschichten, die die Leute über neue Funktionen und Dinge sagen, die hinzugefügt werden könnten, sind Missverständnisse. Es ist eher eine schlecht gestaltete Codearchitektur als optimierter Code. Sie müssen nichts umschreiben, um neue Elemente hinzuzufügen, wenn Sie ein gutes Code-Design haben.

Wenn Sie zum Beispiel einen A * -Pfadfindungsalgorithmus haben, wäre es nicht besser, ihn so optimal wie möglich zu schreiben? Anstatt später die Hälfte des Codes zu ändern, mussten Sie einige Änderungen am Algorithmus vornehmen, da jetzt andere Methodenaufrufe und Rückrufe erforderlich sind. Und wenn Sie bereits von Anfang an über einen optimierten Code verfügen, sparen Sie viel Zeit. Weil Sie sich Beziehungen zwischen Objekten und deren Interaktion zeichnen können, anstatt blinde Unmengen neuer Skripte zu erstellen und alle Verbindungen sofort herzustellen - dies führt zu unklarem Sphagetti-Code.

Das Letzte, was ich hinzufügen möchte, ist, dass Sie später, auch wenn Sie das Spiel nicht mehr machen möchten, über Ihren optimierten A * -Algorithmus verfügen, den Sie für Ihre nächsten Spiele verwenden können. Wiederverwendbarkeit. Beispielsweise verfügen viele Spiele über Inventar, Pfadfindung, Prozedurgenerierung, Interaktionen zwischen NPC, Kampfsystem, KI, Schnittstelleninteraktion und Eingabeverwaltung. Jetzt sollten Sie sich fragen: "Wie oft habe ich diese Elemente von Grund auf neu geschrieben?" Sie sind 70-80% des Spiels. Müssen Sie sie wirklich die ganze Zeit neu schreiben? Und wenn sie nicht optimiert sind?

Candid Moon _Max_
quelle
5
Wenn A * Code optimiert werden soll, wie optimiert ist "optimiert"? Codieren Sie Dinge in der Montage, bevor Sie Benchmarks durchführen? Ich denke, im Allgemeinen sollte nicht-triviale Arbeit an Mikrooptimierungen verbleiben, bis Benchmarks durchgeführt wurden. Die Optimierung der Compiler könnte einen besseren Job als man auf den Mikro-Optimierungen tun, und ist viel billiger.
22.
@gmatht Naja A * kann anders sein als ich sagte, es kann schlechtes Design haben und nicht wirklich gut funktionieren. Aber es kann Multithreading, basierend auf Fibonacci-Heap, einige Vorhersagen haben, aufgeteilt in Stücke. Wenn wir über die Wegfindung sprechen, können wir Flow Field hinzufügen, um es mit A * zu mischen. Auch weg glätten, multi höhe. Vielleicht ist A * nicht das beste Beispiel, aber wie gesagt, Optimierungen haben nichts damit zu tun, den Code tatsächlich zu ändern. Der Entwickler ändert den Code, weil er schlecht entworfen wurde, zum Beispiel, weil er SOLID nicht aus einem Grund befolgt habe dieses A * geschrieben, du brauchst es nicht mehr zu schreiben.
Candid Moon_Max_
@gmatht Mikrooptimierungen sind eigentlich nicht das Problem. Ich denke, OP bedeutet eher die beste und effizienteste Art, KI-Verhalten, Shader oder irgendetwas anderes zu berechnen.
Candid Moon_Max_
Wenn Sie wissen, wie man diese Dinge effizient schreibt, sehe ich das Problem nicht. Es wird die gleiche Zeit oder noch weniger dauern. Es hängt mehr von der Erfahrung eines Entwicklers ab. Wenn ich als Programmierer eine bessere Lösung kenne, würde ich keine beschissene schreiben. Wenn ich weiß, wie man Fibonacci-Heap schreibt, verwende ich List und Sorting nicht, um die minimalen oder maximalen Werte zu erhalten. Natürlich wird das Schreiben etwas länger dauern, anstatt List.Sort () zu verwenden. , aber was ist, wenn ich bereits eine wiederverwendbare habe?
Candid Moon_Max_
2
@ CandidMoon Ich bin nicht einverstanden mit "Es wird die gleiche Zeit oder noch weniger dauern." effizienten Code zu schreiben. Vielleicht würde es dieselbe Zeit dauern, Code zu schreiben, der nicht offensichtlich ineffizient ist, aber wenn Sie von "Effizienz" sprechen, müssen Sie Cache-Konflikte in Betracht ziehen, Multithreading hinzufügen, CPU-spezifische Eigenschaften verwenden, die nur auf einigen CPUs verfügbar sind, und Algorithmen für große N aufgrund von O umschalten (N log N) vs O (N) - so etwas ist schwierig und fehleranfällig und benötigt viel mehr Zeit als die einfache Implementierung. Sie tun es nur, wenn Sie wissen, dass es das Endergebnis wesentlich beeinflussen wird.
Michael Anderson