Lohnt sich die Mikrooptimierung bei Mobilgeräten?

Normalerweise wird die Mikrooptimierung mit der folgenden Erklärung als nicht lohnenswert angesehen: Sie beschleunigt das Programm möglicherweise um weniger als ein Prozent, aber niemand kümmert sich um diesen kleinen Schub - das ist einfach zu wenig, um bemerkt zu werden.

Darüber hinaus gibt es möglicherweise einen Ereignishandler, der tausendmal pro Sekunde ausgelöst wird und sehr schnell beendet wird - bevor er erneut ausgelöst wird. Niemand kümmert sich darum, wie schnell es ist - es schneller zu machen, kann nicht bemerkt werden, weil es bereits "so schnell wie beobachtet werden kann".

Bei mobilen Geräten ist der Energieverbrauch jedoch ein wichtiger Faktor. Der gleiche Event-Handler, der für eine um zehn Prozent schnellere Ausführung optimiert wurde, führt zu einem geringeren Energieverbrauch. Dies bedeutet eine längere Akkulaufzeit und ein längeres Betriebsgerät.

Wie genau ist das letztere Urteil über mobile Geräte? Gibt es Beispiele aus dem wirklichen Leben, die dies bestätigen oder widerlegen?

Es lohnt sich, wenn Messungen sagen, dass es sich lohnt. Für mobile Geräte sowie Supercomputer.

EDIT: Wenig vom Thema entfernt, aber über Ihr Beispiel. Wenn das Ereignis zu oft ausgelöst wird, liegt ein Konzeptionsproblem vor, und die Lösung dieses Konzeptionsproblems ist das eigentliche Problem. Machen Sie es nicht weniger sichtbar durch Mikrooptimierung.

Sie können im Rückruf beispielsweise einen Test durchführen, um zu häufige Anrufe zu verwerfen oder die Art und Weise, wie der Rückruf aufgerufen wird, zu überarbeiten.

Im Allgemeinen ist es eine schlechte Praxis, Rückrufe an «kontinuierliche Ereignisse» anzuhängen. Damit meine ich Ereignisse, die nicht einmal ausgelöst und dann ausgeführt werden, sondern die bei Aktionen ausgelöst werden, die über die Zeit andauern.

Das Scrollen einer Seite oder eines Schiebereglers ist beispielsweise ein kontinuierliches Ereignis.

Sie wissen nie, wie oft diese Ereignisse ausgelöst werden. Wenn sie schnell genug ausgelöst werden, wird Ihre Anwendung verzögert, und wenn sie zu oft ausgelöst werden, wird die CPU-Auslastung umsonst sehr hoch sein, was möglicherweise auch zu einer Verzögerung Ihrer Anwendung führt.

Wie genau ist das letztere Urteil über mobile Geräte?

Es ist nur so genau wie die tatsächlichen Messungen auf dem tatsächlichen Gerät, die tatsächlich anzeigen, dass die tatsächliche Optimierung tatsächlich hilft.

Annahmen und Urteile sind wertlos.

Messungen haben Wert.

Jede Optimierung (einschließlich "Mikrooptimierung", was auch immer das ist) ist Zeitverschwendung, bis eine tatsächliche Messung vorliegt, die auf ein tatsächliches Problem hinweist, bei dem der Code tatsächlich einige Anforderungen nicht erfüllt (hinsichtlich Geschwindigkeit, Speicher, Leistung oder Netzwerklatenz oder was auch immer) ).

(Vorausgesetzt, Geschwindigkeit ist Ihr Hauptproblem.) Jeder hat Recht.
Außer - die Messung sagt Ihnen nicht, was Sie optimieren müssen.

Die Messung zeigt Ihnen, dass Sie optimieren müssen.
Die Messung zeigt Ihnen, wie viel Sie bei der Optimierung gespart haben.

Die Messung sagt Ihnen nicht, was Sie optimieren sollen.
Diese Technik zeigt Ihnen, was Sie optimieren müssen.

Ich bin mit Optimierung vertraut. Ich sehe die Programme anderer Leute mit anderen Augen - hier ist meine Einstellung:

Normalerweise wird die Mikrooptimierung mit der folgenden Erklärung als nicht lohnenswert angesehen: Sie beschleunigt das Programm möglicherweise um weniger als ein Prozent, aber niemand kümmert sich um diesen kleinen Schub - das ist einfach zu wenig, um bemerkt zu werden.

Das Lustige ist, eine solche Änderung führt zu 99%. Zehn solcher Änderungen machen das Programm spürbar schneller. Für viele Ingenieure können Änderungen an ihrem Ansatz, ein Programm zu schreiben, dazu führen, dass ein Programm um ein Vielfaches schneller ausgeführt wird. Wenn Sie sich der Effizienz bewusst sind und auf diese Weise schreiben, kann Ihr Programm ohne viel zusätzlichen Aufwand um ein Vielfaches schneller werden. solche Gewinne sind keine Mikrooptimierungen, imo.

Hinweis: Ich schlage in dieser Diskussion niemals kontextbezogene Optimierungen vor.

Darüber hinaus gibt es möglicherweise einen Ereignishandler, der tausendmal pro Sekunde ausgelöst wird und sehr schnell beendet wird - bevor er erneut ausgelöst wird. Niemand kümmert sich darum, wie schnell es ist - es schneller zu machen, kann nicht bemerkt werden, weil es bereits "so schnell wie beobachtet werden kann".

und es erledigt wahrscheinlich bereits mehr Arbeit als nötig, da 1 kHz weitaus höher ist als in vielen Fällen erforderlich. Was ist die Quelle dieses Event-Handlers und welche Auswirkungen hat er? Wenn lediglich die Benutzeroberfläche aktualisiert wird und Ereignisse gesammelt und zusammengeführt werden können, ist der 1-kHz-Versand mit Sicherheit übertrieben (weit mehr als 1% - eher 25x). Bei einem System mit mehreren Quellen, das seriell übertragen wird, ist 1 kHz möglicherweise nicht schnell genug (z. B. MIDI).

Bei mobilen Geräten ist der Energieverbrauch jedoch ein wichtiger Faktor. Der gleiche Event-Handler, der für eine um zehn Prozent schnellere Ausführung optimiert wurde, führt zu einem geringeren Energieverbrauch. Dies bedeutet eine längere Akkulaufzeit und ein längeres Betriebsgerät. Wie genau ist das letztere Urteil über mobile Geräte? Gibt es Beispiele aus dem wirklichen Leben, die dies bestätigen oder widerlegen?

Basierend auf den Programmen, die ich gesehen habe, gibt es nicht sehr viele Leute, die solche Optimierungen in Betracht ziehen (oder sich damit befassen), obwohl eine Änderung Ihrer Herangehensweise beim Schreiben von Programmen unglaubliche Gewinne bringen kann (> 10x oder viel schneller). Viele, die ich gesehen habe (auf der Seite der App-Entwicklung), schreiben einfach und gehen dann von oben nach unten oder "Hagel Mary" vor, wenn (/ wenn) Leistungsprobleme sie einholen. In ähnlicher Weise werden sich viele nicht einmal die Zeit nehmen, um ein Profil zu erstellen, bis ein solches Ereignis eintritt. Bis dahin macht es das Rauschen so vieler zusammengesetzter Ineffizienzen sehr schwierig, nützliche Informationen von einem Profiler zu erhalten. Beispiele für den Hagel-Mary-Ansatz wären die Optimierung der falschen Bereiche (mit oder ohne Suche nach Problembereichen) oder einfach das Werfen von mehr Kernen auf Problembereiche. Dies geschieht, anstatt vorhandene Ineffizienzen zu beheben.

Für das typische existierende Programm (unter den mobilen Programmen, die ich gesehen habe) war die Optimierung beim Schreiben kein großes Problem. "Ja", sie sind (im typischen Fall) die Zeit wert, vorausgesetzt, es ist im Budget und eine Priorität. In diesem Fall können die zehn Änderungen, die das Programm spürbar beschleunigen, wahrscheinlich in wenigen Stunden und weniger als einem Tag durchgeführt werden.

"Faul schreiben und im Nachhinein profilieren" als einzige Maßnahme zur Verbesserung eines Programms ist eine schreckliche Idee: Nehmen Sie sich die Zeit, um zu lernen, wie man ein effizientes Programm schreibt (wie es geschrieben wird, nicht indem Sie es am Ende zusammenkleben) Ansatz (imo); Verwenden Sie die richtigen Algorithmen, verbieten Sie verschwenderisches Kopieren, Zuordnungen und Berechnungen (+ viele, viele andere Kategorien). Natürlich hat die Analyse der Leistung im Nachhinein ihre Vorzüge, aber wenn Sie das Programm von Anfang an so schreiben, dass es effizient ist, erhalten Sie ein völlig neues Effizienzniveau, da Sie viel lernen und die Ausführung aus verschiedenen Perspektiven betrachten und bewerten.

Die andere Sache ist, dass Programme (oft) zur Wiederverwendung geschrieben werden sollten. Ein schlecht geschriebenes Programm führt zu Änderungen, die die Programme der Clients beschädigen können, wenn die Ineffizienzen beseitigt werden (oder einfach ineffizient bleiben, um zu vermeiden, dass vorhandene Programme beschädigt werden).

Ein großer Vorteil der Berücksichtigung beim Schreiben besteht darin, dass Sie eine sehr klare Vorstellung davon haben, wie das Programm funktioniert (obwohl es kein vollständiges Bild ist). Sie können diese Informationen verwenden, um das Design der Schnittstellen und die Speicherung der Daten zu unterstützen . die Wahrheit ist, ein Ingenieur kann etwas implementieren , die mehrere (zB> 10x) mal schneller als der Standard „one size fits all“ -Lösungen mit dem Betriebssystem zur Verfügung gestellt.

Schließlich lohnt es sich auch über mobile Geräte hinaus. Es gibt viele ineffiziente Programme, die mit der Einstellung geschrieben wurden, dass Hardware in zwei Jahren schneller sein wird (häufige Gründe, selbst für heute geschriebene Programme!). Das ist zwar nicht falsch , aber zu optimistisch. Parallelisierung hat ebenfalls einen Zweck, ist jedoch für viele Programme die falsche "Standardlösung". Viele dieser bestehenden Programme können am besten verbessert werden, indem zunächst die vorhandenen Ineffizienzen beseitigt werden.

Also ... es gibt normalerweise eine Tonne dieser 1%, 2%, 7% (und viel schlimmeren) Fälle in der realen Welt. Das Korrigieren oder (was noch wichtiger ist) das Nichtschreiben / Belichten überhaupt kann große Vorteile bringen. Viele dieser Fälle können leicht lokalisiert und korrigiert werden (vorausgesetzt, der Ingenieur hat Erfahrung damit). Es kann jedoch wirklich schmerzhaft sein, diese nachträglich zu korrigieren und erneut zu testen. Wenn ein Programm optimal ist, wird es idealerweise von Anfang an so geschrieben.

Als Endbenutzer ist es irritierend, ständig auf langsame Programme zu warten und die doppelte Hardware auf Probleme zu werfen, die durch langsame / ineffiziente Programme verursacht werden: F: "Was werden Sie jetzt tun, wenn Sie doppelt so viele Kerne und doppelt so viel Speicher haben?" A: "Gewinnen Sie die Reaktionsfähigkeit und Produktivität zurück, die ich vor dem Upgrade meiner Software hatte - das war's". ziemlich rücksichtslos vom Entwickler (imho).

Der Grund , warum Sie sollten nicht mit Mühe Mikro - Optimierungen ist , dass sie Mikrooptimierungen. Sie sollten auf das größere Bild zu sehen und stattdessen Ihre Zeit auf verschwenden Mikro - Optimierungen, finden Gründe für echte Verbesserungen.

Meine Faustregel lautet, dass jeder Code, der ohne Rücksicht auf die Geschwindigkeit geschrieben wurde, aber auch nicht völlig dumm ist, mit viel Aufwand zehnmal schneller gemacht werden kann. 10% durch Mikrooptimierungen sind nichts, mit dem ich mich beschäftigen würde. Ich bin sicher, Sie können mit weniger Aufwand viel größere Einsparungen erzielen.

Andererseits bestand "Optimierung" bei kommerziellen Produkten in den letzten Jahren für mich hauptsächlich darin, Code zu finden, der Zeit verschwendete und nicht verschwendete. Mehr Unpessimisierung als Optimierung.

(Auf der anderen Seite haben einige Leute das Gefühl, dass vorzeitige Optimierung böse ist. Wenn es also einen Weg A gibt, etwas zu tun, und einen Weg B, der weniger effizient ist, wählen sie B, weil A "vorzeitige Optimierung" ist. Manche Leute sind einfach nur dumm).