Wann ist der Leistungszuwachs signifikant genug, um diese Optimierung zu implementieren?

Ich denke, die Faustregel (zumindest für mich) ist zweifach:

1. "Es kommt darauf an, wenn es darauf ankommt" - in der Geschäftswelt bedeutet das im Allgemeinen, dass es wichtig ist, wenn die Kunden sich darum kümmern. Das heißt, wenn die Endbenutzer den Unterschied zwischen 100ms und 90ms "bemerken" (ich bin hier nicht witzig), dann ist es wichtig.
2. Wenn "es wichtig ist", sollten Sie Ihren Code sorgfältig auf eine realistische Vielzahl von Anwendungsfällen testen, die wahrscheinlich entstehen oder zumindest auftreten können. Wenn eine Optimierung den Code in 50% der Fälle beschleunigt, aber tatsächlich langsamer läuft als in den anderen 50% der Zeit, ist die Implementierung möglicherweise nicht sinnvoll.

Zu Punkt 1 oben: Wenn Sie vorschlagen, dass ein Endnutzer Ihrer Software einen Unterschied von 10 ms "bemerkt", möchte ich nicht vorschlagen, dass sie tatsächlich einen Unterschied sehen werden. Wenn Ihre App jedoch auf einem Server mit Millionen von Verbindungen ausgeführt wird und jede kleine Geschwindigkeitssteigerung den Server erheblich entlastet, kann dies für den Client, auf dem der Server ausgeführt wird, von Bedeutung sein. Oder wenn Ihre App extrem zeitkritische Arbeit leistet, ist dies ein weiterer Fall, in dem das Ergebnis einer 10ms-Beschleunigung wahrnehmbar ist, auch wenn die Beschleunigung selbst nicht ist / p>     

Der einzig vernünftige Ansatz für Ihre Frage ist etwas wie "wenn der Nutzen groß genug ist, um die Zeit zu rechtfertigen, die Sie investieren, um die Optimierung zu erforschen, zu implementieren und zu testen."

Der "Nutzen ist groß genug" ist äußerst subjektiv. Können Sie oder Ihr Arbeitgeber mehr Softwareeinheiten verkaufen, wenn Sie diese Änderung vornehmen? Wird Ihre Benutzerbasis benachrichtigt? Wird es Ihnen persönliche Befriedigung geben, den schnellstmöglichen Code zu haben? Welche dieser oder ähnlicher Fragen gelten, ist etwas, das nur Sie kennen können.

Im Großen und Ganzen war die meiste Software, die ich geschrieben habe (in einer mehr als 20-jährigen Karriere), "schnell genug" out of the box und der Code, den ich optimieren wollte, stellte sich als offensichtlicher Engpass für die Endnutzer heraus : Abfragen dauern lange, scrollen zu langsam, so etwas.

Donald Knuth machte die folgenden zwei Aussagen zur Optimierung:

  

"Wir sollten klein vergessen   Effizienz, sagen etwa 97% der   Zeit: vorzeitige Optimierung ist die   Wurzel allen Übels "[2]

und

  

"In etabliertem Engineering   Disziplinen eine 12% Verbesserung, leicht   erhalten, wird nie als marginal angesehen   und ich glaube denselben Standpunkt   sollte in Software vorherrschen   Technik "[5]

src: Ссылка

• Optimiert die Optimierung Ihren Code zu sehr?
• Brauchen Sie wirklich eine Optimierung? Wenn Ihre App gut läuft, ist die Lesbarkeit des Codes wahrscheinlich wichtiger
• Haben Sie an dem allgemeinen Design und den Algorithmen Ihrer Anwendung gearbeitet, bevor Sie kleine Hacky-Optimierungen ausprobieren?

Sie sollten die Optimierungsbemühungen auf die Teile des Codes konzentrieren, die die meiste Laufzeit ausmachen. Wenn ein bestimmter Codeabschnitt 80% der Gesamtlaufzeit ausmacht, hat die Optimierung um 5% weniger Zeitverlust als die Reduzierung des restlichen Codes um 20%.

Im Allgemeinen machen Optimierungen den Code weniger lesbar (nicht immer, aber oft). Daher sollten Sie die Optimierung so lange vermeiden, bis Sie sicher sind, dass ein Problem vorliegt.

Solange es schnell genug ist, müssen Sie nicht mehr optimieren. Aber dann würden Sie nicht einmal Profiling machen, wenn das der Fall wäre ...

Wenn der Leistungszuwachs gering ist, berücksichtigen Sie die anderen Faktoren: Wartungsfreundlichkeit, Änderungsrisiko, Verständlichkeit usw. Wenn die Fähigkeit zur Pflege oder zum Verständnis des Codes eingeschränkt wird, ist dies wahrscheinlich nicht sinnvoll. Wenn es diese Attribute verbessert, ist es mehr Grund, die Änderung zu implementieren.

In den meisten Fällen ist Ihre Zeit wertvoller als die des Computers. Wenn Sie denken, dass es eine halbe Stunde länger dauert, um herauszufinden, was der Code später macht (sagen Sie, wenn es einen Fehler gibt), und es nur Sie nur ein paar Sekunden gespeichert hat, sind Sie bei einem Nettoverlust.

Es kommt sehr auf das Nutzungsszenario an. Ich gehe hier davon aus, dass der fragliche Code profiliert wurde und somit als der Flaschenhals bekannt ist - d. nicht nur "das könnte schneller sein", sondern "das Programm würde Ergebnisse liefern / schneller fertig werden, wenn das schneller wäre". In Situationen, in denen dies nicht der Fall ist, z. Wenn Sie 99% Ihrer Zeit damit verbringen, darauf zu warten, dass mehr Daten über eine Ethernet-Verbindung übertragen werden, sollten Sie auf Korrektheit achten, aber nicht auf Geschwindigkeit.

• Wenn Sie einen Code für die Benutzeroberfläche schreiben, ist die wahrgenommene Geschwindigkeit das, was Ihnen am Herzen liegt. Im Allgemeinen wird alles unter ~ 100 ms als "Instant" wahrgenommen - kein Punkt beschleunigt es.
• Wenn Sie einen Code für eine riesige Serverfarm schreiben, dann ist es lohnenswert, wenn die Kosten für Ihr Gehalt, um den Code schnell zu machen, geringer sind als die Kosten für den zusätzlichen Strom für die Serverfarm. (Aber achten Sie auf Ihre Zeit.)
• Wenn Sie einen Code schreiben, der nur selten oder unbeaufsichtigt verwendet wird, sollten Sie sich keine Sorgen machen, solange er halbwegs gesund ist. Installations-Skripte sind in der Regel von dieser Art (es sei denn, Sie beginnen in vielen Minuten zu laufen, zu welchem ​​Zeitpunkt Benutzer die Installation möglicherweise abbrechen, weil sie zu lange dauert).
• Wenn Sie Code schreiben, um eine Aufgabe für jemand anderen zu automatisieren, dann ist es sinnvoll, wenn (Ihre Programmierzeit + die Zeit, die Sie mit dem optimierten Code verbracht haben) geringer ist als die Zeit, die Sie mit dem langsamen Code verbracht haben. Wenn Sie dies in einer kommerziellen Umgebung tun, gewichten Sie dies durch Ihre jeweiligen Gehälter.
• Wenn Sie einen Bibliothekscode schreiben, der von vielen tausend Menschen verwendet wird, sollten Sie immer schneller sein, wenn Sie Zeit dazu haben.
• Wenn Sie unter Zeitdruck stehen, einfach etwas zu haben, das z. als Demo, nicht optimieren (außer durch sinnvolle Wahl von Algorithmen aus Bibliotheken), es sei denn, das Ergebnis wäre so langsam, dass es nicht einmal "funktioniert".

Einer der größten Ärgernisse für mich persönlich ist das Finden von Software, die vielleicht zunächst in eine Kategorie fiel und später in eine andere fiel, für die aber niemand mehr benötigte Optimierungen vorgenommen hat. Bis vor kurzem war die Javascript-Performance ein großartiges Beispiel dafür. Moral der Geschichte ist: Entscheide dich nicht nur einmal; Überarbeiten Sie das Problem, wie es die Situation erfordert.