Es ist erwähnenswert, dass Knuths ursprüngliches Zitat aus einem Artikel stammt, den er verfasst hat, um die Verwendung gotoin sorgfältig ausgewählten und gemessenen Bereichen zu fördern , um Hotspots zu beseitigen. Sein Zitat war eine Einschränkung, die er hinzufügte, um seine Gründe für die gotoBeschleunigung dieser kritischen Schleifen zu rechtfertigen .
[...] Dies ist wiederum eine spürbare Einsparung der Gesamtlaufgeschwindigkeit, wenn beispielsweise der Durchschnittswert von n etwa 20 beträgt und die Suchroutine etwa eine Million Mal im Programm ausgeführt wird. Solche Schleifenoptimierungen gotossind nicht schwer zu erlernen und, wie ich bereits sagte, nur für einen kleinen Teil eines Programms geeignet, führen jedoch häufig zu erheblichen Einsparungen. [...]
Und weiter:
Die konventionelle Weisheit, die viele der heutigen Softwareentwickler teilen, erfordert, die Effizienz im Kleinen zu ignorieren. Aber ich glaube, dies ist einfach eine Überreaktion auf die Missbräuche, die von Pennywise-and-Pound-Dummkopf-Programmierern praktiziert werden, die ihre "optimierten" Programme nicht debuggen oder warten können. In etablierten Ingenieurdisziplinen wird eine leicht zu erreichende Verbesserung von 12% niemals als marginal angesehen. und ich glaube, dass der gleiche Standpunkt in der Softwareentwicklung vorherrschen sollte. Natürlich würde ich mich nicht darum kümmern, solche Optimierungen bei einem One-Shot-Job vorzunehmen, aber wenn es um die Vorbereitung von Qualitätsprogrammen geht, möchte ich mich nicht auf Tools beschränken, die mir solche Effizienz verweigern [dh goto
Aussagen in diesem Zusammenhang].
Denken Sie daran, wie er in Anführungszeichen "optimiert" verwendet hat (die Software ist wahrscheinlich nicht wirklich effizient). Beachten Sie auch, dass er nicht nur diese "Pennywise-and-Pound-Dummkopf" -Programmierer kritisiert, sondern auch die Leute, die darauf reagieren, indem sie vorschlagen, dass Sie kleine Ineffizienzen immer ignorieren sollten. Zum abschließenden Teil:
Es besteht kein Zweifel, dass der Gral der Effizienz zu Missbrauch führt. Programmierer verschwenden enorm viel Zeit damit, über die Geschwindigkeit unkritischer Teile ihrer Programme nachzudenken oder sich darüber Gedanken zu machen, und diese Effizienzversuche wirken sich tatsächlich stark negativ aus, wenn Debugging und Wartung in Betracht gezogen werden. Wir sollten kleine Wirkungsgrade vergessen, sagen wir 97% der Zeit; Vorzeitige Optimierung ist die Wurzel allen Übels.
... und noch etwas mehr über die Bedeutung von Profiling-Tools:
Es ist oft ein Fehler, a priori zu beurteilen, welche Teile eines Programms wirklich kritisch sind, da die universelle Erfahrung von Programmierern, die Messwerkzeuge verwendet haben, darin bestand, dass ihre intuitiven Vermutungen fehlschlagen. Nachdem ich sieben Jahre lang mit solchen Tools gearbeitet habe, bin ich davon überzeugt, dass alle von nun an geschriebenen Compiler so konzipiert sein sollten, dass sie allen Programmierern Feedback geben, welche Teile ihrer Programme am meisten kosten. In der Tat sollte dieses Feedback automatisch bereitgestellt werden, es sei denn, es wurde speziell deaktiviert.
Die Leute haben sein Zitat überall missbraucht und oft darauf hingewiesen, dass Mikrooptimierungen verfrüht sind, als sein gesamtes Papier Mikrooptimierungen befürwortete! Eine der von ihm kritisierten Personengruppen, die diese "konventionelle Weisheit" wiederholen, weil er die Effizienz im Kleinen immer ignoriert, missbraucht häufig sein Zitat, das ursprünglich teilweise gegen solche Typen gerichtet war, die alle Formen der Mikrooptimierung abschrecken .
Es war jedoch ein Zitat zugunsten angemessen angewandter Mikrooptimierungen, wenn diese von einer erfahrenen Hand mit einem Profiler verwendet wurden. Das heutige analoge Äquivalent könnte lauten: "Menschen sollten bei der Optimierung ihrer Software keine blinden Stiche machen, aber benutzerdefinierte Speicherzuordnungen können einen großen Unterschied machen, wenn sie in Schlüsselbereichen angewendet werden, um die Referenzlokalität zu verbessern" oder " Handgeschriebener SIMD-Code mit einem SoA rep ist wirklich schwer zu pflegen und sollte nicht überall verwendet werden, aber es kann viel schneller Speicher verbrauchen, wenn es von einer erfahrenen und geführten Hand angemessen angewendet wird. "
Jedes Mal, wenn Sie versuchen, sorgfältig angewandte Mikrooptimierungen zu fördern, wie Knuth es oben beworben hat, ist es gut, einen Haftungsausschluss einzufügen, um Neulinge davon abzuhalten, zu aufgeregt zu werden und blindlings Optimierungen vorzunehmen, z. B. ihre gesamte Software für die Verwendung neu zu schreiben goto. Das war zum Teil das, was er tat. Sein Zitat war praktisch Teil eines großen Haftungsausschlusses, genau wie jemand, der ein Motorrad über eine brennende Feuerstelle springt, einen Haftungsausschluss hinzufügen könnte, dass Amateure dies nicht zu Hause versuchen sollten, während sie gleichzeitig diejenigen kritisieren, die es ohne angemessenes Wissen und Ausrüstung versuchen und verletzt werden .
Was er als "vorzeitige Optimierungen" ansah, waren Optimierungen, die von Leuten angewendet wurden, die effektiv nicht wussten, was sie taten: Sie wussten nicht, ob die Optimierung wirklich benötigt wurde, maßen nicht mit geeigneten Werkzeugen, verstanden vielleicht nicht die Natur von Ihre Compiler- oder Computerarchitektur und vor allem ihre "Pennywise-and-Pound-Dummheit" waren, was bedeutete, dass sie die großen Möglichkeiten zur Optimierung (Einsparung von Millionen von Dollar) übersehen, indem sie versuchten, ein paar Cent zu kneifen, und während sie Code erstellten, den sie nicht können länger effektiv debuggen und warten.
Wenn Sie nicht in die Kategorie "Pennywise-and-Pound-Dummkopf" passen, optimieren Sie nicht vorzeitig nach Knuths Maßstäben, selbst wenn Sie a gotoverwenden, um eine kritische Schleife zu beschleunigen (was unwahrscheinlich ist) um viel gegen die heutigen Optimierer zu helfen, aber wenn es so wäre und in einem wirklich kritischen Bereich, dann würden Sie nicht vorzeitig optimieren). Wenn Sie tatsächlich alles anwenden, was Sie in Bereichen tun, die wirklich gebraucht werden und von denen sie wirklich profitieren, dann sind Sie in den Augen von Knuth einfach großartig.