Was ist die lächerlichste Pessimisierung, die Sie gesehen haben? [geschlossen]

Wir alle wissen, dass vorzeitige Optimierung die Wurzel allen Übels ist, weil sie zu unlesbarem / nicht wartbarem Code führt. Noch schlimmer ist die Pessimisierung, wenn jemand eine "Optimierung" implementiert, weil er glaubt , dass sie schneller sein wird, aber am Ende langsamer, fehlerhaft, nicht wartbar usw. Was ist das lächerlichste Beispiel dafür, das Sie gesehen haben ?

Bei einem alten Projekt haben wir einige (ansonsten ausgezeichnete) Programmierer für eingebettete Systeme geerbt, die über umfangreiche Erfahrung mit Z-8000 verfügten.

Unsere neue Umgebung war 32-Bit-Sparc Solaris.

Einer der Jungs hat alle Ints in Shorts geändert, um unseren Code zu beschleunigen, da das Abrufen von 16 Bit aus dem RAM schneller war als das Abrufen von 32 Bit.

Ich musste ein Demo-Programm schreiben, um zu zeigen, dass das Abrufen von 32-Bit-Werten auf einem 32-Bit-System schneller war als das Abrufen von 16-Bit-Werten, und erklären, dass die CPU zum Abrufen eines 16-Bit-Werts eine 32-Bit-Breite erstellen musste Speicherzugriff und dann Maskieren oder Verschieben der für den 16-Bit-Wert nicht benötigten Bits.

Ich denke, der Ausdruck "vorzeitige Optimierung ist die Wurzel allen Übels" wird weit überstrapaziert. Für viele Projekte ist es eine Ausrede geworden, die Leistung erst spät in einem Projekt zu berücksichtigen.

Dieser Satz ist oft eine Krücke für Menschen, um Arbeit zu vermeiden. Ich sehe diesen Satz verwendet, wenn die Leute wirklich sagen sollten: "Gee, wir haben wirklich nicht daran gedacht und haben jetzt keine Zeit, uns damit zu befassen."

Ich habe viel mehr "lächerliche" Beispiele für dumme Leistungsprobleme gesehen als Beispiele für Probleme, die aufgrund von "Pessimisierung" eingeführt wurden.

• Lesen des gleichen Registrierungsschlüssels tausende (oder zehntausende) Mal während des Programmstarts.
• Laden Sie dieselbe DLL hunderte oder tausende Male
• Verschwenden Sie Mega-Bytes an Speicher, indem Sie die vollständigen Pfade zu Dateien unnötig beibehalten
• Sie organisieren keine Datenstrukturen, sodass sie viel mehr Speicher beanspruchen als sie benötigen
• Größe aller Zeichenfolgen, in denen Dateinamen oder Pfade zu MAX_PATH gespeichert sind
• Kostenlose Abfrage nach Dingen, die Ereignisse, Rückrufe oder andere Benachrichtigungsmechanismen haben

Was ich für eine bessere Aussage halte, ist folgende: "Optimierung ohne Messen und Verstehen ist überhaupt keine Optimierung - es ist nur eine zufällige Änderung".

Gute Leistung ist zeitaufwändig - oft mehr als die Entwicklung des Features oder der Komponente selbst.

Datenbanken sind Pessimierungsspielland.

Zu den Favoriten gehören:

• Teilen Sie eine Tabelle in Vielfache auf (nach Datumsbereich, alphabetischem Bereich usw.), da sie "zu groß" ist.
• Erstellen Sie eine Archivtabelle für zurückgezogene Datensätze, fahren Sie jedoch mit der Produktionstabelle mit UNION fort.
• Duplizieren Sie ganze Datenbanken nach (Abteilung / Kunde / Produkt / etc.)
• Widerstehen Sie dem Hinzufügen von Spalten zu einem Index, da dieser zu groß wird.
• Erstellen Sie viele Übersichtstabellen, da die Neuberechnung aus Rohdaten zu langsam ist.
• Erstellen Sie Spalten mit Unterfeldern, um Platz zu sparen.
• Denormalisieren Sie in Felder als Array.

Das ist mir ein Rätsel.

Ich denke, es gibt keine absolute Regel: Einige Dinge werden am besten im Voraus optimiert, andere nicht.

Ich habe zum Beispiel in einer Firma gearbeitet, in der wir Datenpakete von Satelliten erhalten haben. Jedes Paket hat viel Geld gekostet, daher wurden alle Daten stark optimiert (dh gepackt). Zum Beispiel wurde Breiten- / Längengrad nicht als Absolutwerte (Floats) gesendet, sondern als Offsets relativ zur "Nordwesten" -Ecke einer "aktuellen" Zone. Wir mussten alle Daten entpacken, bevor sie verwendet werden konnten. Aber ich denke, dies ist keine Pessimierung, sondern eine intelligente Optimierung, um die Kommunikationskosten zu senken.

Andererseits haben unsere Softwarearchitekten entschieden, dass die entpackten Daten in ein gut lesbares XML-Dokument formatiert und als solches in unserer Datenbank gespeichert werden sollten (im Gegensatz dazu, dass jedes Feld in einer entsprechenden Spalte gespeichert wird). Ihre Idee war, dass "XML die Zukunft ist", "Speicherplatz ist billig" und "Prozessor ist billig", so dass nichts optimiert werden musste. Das Ergebnis war, dass unsere 16-Byte-Pakete in 2-KB-Dokumente umgewandelt wurden, die in einer Spalte gespeichert waren, und dass wir selbst für einfache Abfragen Megabyte an XML-Dokumenten in den Speicher laden mussten! Wir haben über 50 Pakete pro Sekunde erhalten, sodass Sie sich vorstellen können, wie schrecklich die Leistung wurde (übrigens, das Unternehmen ging bankrott).

Es gibt also wieder keine absolute Regel. Ja, manchmal ist eine zu frühe Optimierung ein Fehler. Aber manchmal ist das Motto "CPU / Speicherplatz / Speicher ist billig" die wahre Wurzel allen Übels.

Oh mein Gott, ich glaube ich habe sie alle gesehen. Meistens ist es eine Anstrengung, Leistungsprobleme von jemandem zu beheben, der zu faul ist, um Fehler bis zur URSACHE dieser Leistungsprobleme zu beheben oder sogar zu untersuchen, ob tatsächlich ein Leistungsproblem vorliegt. In vielen dieser Fälle frage ich mich, ob es nicht nur darum geht, dass diese Person eine bestimmte Technologie ausprobieren möchte und verzweifelt nach einem Nagel sucht, der zu ihrem glänzenden neuen Hammer passt.

Hier ist ein aktuelles Beispiel:

Der Datenarchitekt kommt zu mir mit einem ausführlichen Vorschlag, eine Schlüsseltabelle in einer ziemlich großen und komplexen Anwendung vertikal zu partitionieren. Er möchte wissen, welche Art von Entwicklungsaufwand notwendig wäre, um sich auf die Veränderung einzustellen. Das Gespräch lief folgendermaßen ab:

Ich: Warum denkst du darüber nach? Was ist das Problem, das Sie lösen möchten?

Ihm: Tabelle X ist zu breit, wir partitionieren sie aus Leistungsgründen.

Ich: Warum denkst du, dass es zu breit ist?

Ihm: Der Berater sagte, das seien viel zu viele Spalten, um sie in einer Tabelle zu haben.

Ich: Und das wirkt sich auf die Leistung aus?

Ihm: Ja, Benutzer haben zeitweise Verlangsamungen im XYZ-Modul der Anwendung gemeldet.

Ich: Woher wissen Sie, dass die Breite der Tabelle die Ursache des Problems ist?

Ihm: Das ist die Schlüsseltabelle, die vom XYZ-Modul verwendet wird, und sie entspricht 200 Spalten. Es muss das Problem sein.

Ich (Erklären): Das Modul XYZ verwendet jedoch insbesondere die meisten Spalten in dieser Tabelle, und die verwendeten Spalten sind unvorhersehbar, da der Benutzer die App so konfiguriert, dass die Daten angezeigt werden, die aus dieser Tabelle angezeigt werden sollen. Es ist wahrscheinlich , dass 95% der Zeit würden wir alle die Tische wieder zusammen sowieso Verbindungs aufzuwickeln , was würde verletzt Leistung.

Ihm: Der Berater sagte, es sei zu breit und wir müssen es ändern.

Ich: Wer ist dieser Berater? Ich wusste nicht, dass wir einen Berater eingestellt haben, und sie haben überhaupt nicht mit dem Entwicklungsteam gesprochen.

Ihm: Nun, wir haben sie noch nicht eingestellt. Dies ist Teil eines Vorschlags, den sie angeboten haben, aber sie bestanden darauf, dass wir diese Datenbank neu gestalten müssen.

Ich: Ähhh. Der Berater, der Dienstleistungen zur Neugestaltung von Datenbanken verkauft, ist der Meinung, dass wir eine Neugestaltung der Datenbank benötigen.

Das Gespräch ging so weiter und weiter. Danach habe ich mir die fragliche Tabelle noch einmal angesehen und festgestellt, dass sie wahrscheinlich durch eine einfache Normalisierung eingegrenzt werden kann, ohne dass exotische Partitionierungsstrategien erforderlich sind. Dies stellte sich natürlich als strittiger Punkt heraus, als ich die Leistungsprobleme (zuvor nicht gemeldet) untersuchte und sie auf zwei Faktoren zurückführte:

1. Fehlende Indizes für einige Schlüsselspalten.
2. Einige betrügerische Datenanalysten, die regelmäßig Schlüsseltabellen (einschließlich der "zu breiten") sperrten, indem sie die Produktionsdatenbank direkt mit MSAccess abfragten.

Natürlich drängt der Architekt immer noch auf eine vertikale Aufteilung des Tisches, die am "zu breiten" Metaproblem festhält. Er unterstützte seinen Fall sogar, indem er einen Vorschlag von einem anderen Datenbankberater erhielt, der feststellen konnte, dass wir größere Designänderungen an der Datenbank benötigten, ohne auf die App zu schauen oder eine Leistungsanalyse durchzuführen.

Ich habe Leute gesehen, die Alphadrive-7 verwendeten, um CHX-LT vollständig zu inkubieren. Dies ist eine ungewöhnliche Praxis. Die üblichere Praxis besteht darin, den ZT-Transformator so zu initialisieren, dass die Pufferung verringert wird (aufgrund eines höheren Nettoüberlastungswiderstands) und Bytegraphien im Java-Stil zu erstellen.

Total pessimistisch!

Ich gebe zu, nichts Erderschütterndes, aber ich habe Leute erwischt, die StringBuffer verwenden, um Strings außerhalb einer Schleife in Java zu verketten. Es war so einfach wie sich zu drehen

String msg = "Count = " + count + " of " + total + ".";

in

StringBuffer sb = new StringBuffer("Count = ");
sb.append(count);
sb.append(" of ");
sb.append(total);
sb.append(".");
String msg = sb.toString();

Früher war es üblich, die Technik in einer Schleife anzuwenden, da sie messbar schneller war. Die Sache ist, StringBuffer ist synchronisiert, so dass es tatsächlich zusätzlichen Aufwand gibt, wenn Sie nur ein paar Strings verketten. (Ganz zu schweigen davon, dass der Unterschied auf dieser Skala absolut trivial ist.) Zwei weitere Punkte zu dieser Praxis:

1. StringBuilder ist nicht synchronisiert und sollte daher StringBuffer vorgezogen werden, wenn Ihr Code nicht von mehreren Threads aufgerufen werden kann.
2. Moderne Java-Compiler verwandeln lesbare String-Verkettung in optimierten Bytecode für Sie, wenn dies ohnehin angemessen ist.

Ich habe einmal eine MSSQL-Datenbank gesehen, die eine 'Root'-Tabelle verwendet hat. Die Root-Tabelle hatte vier Spalten: GUID (Uniqueidentifier), ID (Int), LastModDate (Datum / Uhrzeit) und CreateDate (Datum / Uhrzeit). Alle Tabellen in der Datenbank wurden mit einem Fremdschlüssel für die Root-Tabelle versehen. Wann immer eine neue Zeile in einer Tabelle in der Datenbank erstellt wurde, mussten Sie einige gespeicherte Prozeduren verwenden, um einen Eintrag in die Root-Tabelle einzufügen, bevor Sie zu der eigentlichen Tabelle gelangen konnten, die Ihnen wichtig war (und nicht zu der Datenbank, für die der Job ausgeführt wurde) Sie mit ein paar Auslösern einfache Auslöser).

Dies verursachte ein Durcheinander von nutzlosem Abhören und Kopfschmerzen, erforderte alles, was darüber geschrieben war, um Sprocs zu verwenden (und beseitigte meine Hoffnungen, LINQ in das Unternehmen einzuführen. Es war möglich, aber die Kopfschmerzen nicht wert), und um das Ganze abzurunden, tat es nicht. Ich kann nicht einmal das erreichen, was es tun sollte.

Der Entwickler, der diesen Pfad gewählt hat, hat ihn unter der Annahme verteidigt, dass dies viel Platz gespart hat, weil wir keine Guids für die Tabellen selbst verwendet haben (aber ... wird nicht für jede von uns erstellte Zeile eine GUID in der Root-Tabelle generiert?) , verbesserte irgendwie die Leistung und machte es "einfach", Änderungen an der Datenbank zu überwachen.

Oh, und das Datenbankdiagramm sah aus wie eine mutierte Spinne aus der Hölle.

Wie wäre es mit POBI - Pessimisierung offensichtlich absichtlich?

Mein Kollege in den 90er Jahren hatte es satt, vom CEO in den Arsch getreten zu werden, nur weil der CEO den ersten Tag jeder ERP-Software-Version (eine benutzerdefinierte) damit verbracht hatte, Leistungsprobleme in den neuen Funktionen zu lokalisieren. Selbst wenn die neuen Funktionen Gigabyte knirschten und das Unmögliche möglich machten, fand er immer ein Detail oder sogar ein scheinbar großes Problem, über das er jammern konnte. Er glaubte viel über das Programmieren zu wissen und bekam seine Tritte, indem er Programmierern in den Arsch trat.

Aufgrund der Inkompetenz der Kritik (er war ein CEO, kein IT-Mann) gelang es meinem Kollegen nie, es richtig zu machen. Wenn Sie kein Leistungsproblem haben, können Sie es nicht beseitigen ...

Bis zu einer Veröffentlichung hat er viele Delay (200) -Funktionsaufrufe (es war Delphi) in den neuen Code eingefügt. Es dauerte nur 20 Minuten nach der Inbetriebnahme, und er wurde angewiesen, im Büro des CEO zu erscheinen, um seine überfälligen Beleidigungen persönlich zu holen.

Bisher war es nur ungewöhnlich, dass meine Kollegen stumm waren, als er zurückkam, lächelte, scherzte, ein oder zwei BigMacs ausging, während er normalerweise gegen Tische trat, über den CEO und das Unternehmen flammte und den Rest des Tages zu Tode verbrachte .

Natürlich ruhte sich mein Kollege jetzt ein oder zwei Tage an seinem Schreibtisch aus und verbesserte seine Zielfähigkeiten in Quake. Am zweiten oder dritten Tag löschte er die Verzögerungsaufrufe, baute sie neu auf und veröffentlichte einen "Notfall-Patch", von dem er das Wort verbreitete dass er 2 Tage und 1 Nacht verbracht hatte, um die Leistungslöcher zu reparieren.

Dies war das erste (und einzige) Mal, dass der böse CEO "großartige Arbeit!" Sagte. zu ihm. Das ist alles was zählt, oder?

Das war echtes POBI.

Es ist aber auch eine Art Optimierung sozialer Prozesse, also 100% in Ordnung.

Meiner Ansicht nach.

"Datenbankunabhängigkeit". Dies bedeutete keine gespeicherten Prozesse, Trigger usw. - nicht einmal Fremdschlüssel.

var stringBuilder = new StringBuilder();
stringBuilder.Append(myObj.a + myObj.b + myObj.c + myObj.d);
string cat = stringBuilder.ToString();

Beste Verwendung eines StringBuilder, den ich je gesehen habe.

Verwenden eines regulären Ausdrucks zum Teilen eines Strings, wenn ein einfacher string.split ausreicht

Sehr spät zu diesem Thread weiß ich, aber ich habe das kürzlich gesehen:

bool isFinished = GetIsFinished();

switch (isFinished)
{
    case true:
        DoFinish();
        break;

    case false:
        DoNextStep();
        break;

    default:
        DoNextStep();
}

Weißt du, nur für den Fall, dass ein Boolescher Wert einige zusätzliche Werte hat ...

Das schlechteste Beispiel, das ich mir vorstellen kann, ist eine interne Datenbank in meinem Unternehmen, die Informationen zu allen Mitarbeitern enthält. Es erhält ein nächtliches Update von HR und verfügt über einen ASP.NET-Webdienst. Viele andere Apps verwenden den Webdienst, um beispielsweise Such- / Dropdown-Felder zu füllen.

Der Pessimismus besteht darin, dass der Entwickler der Meinung war, dass wiederholte Aufrufe des Webdienstes zu langsam wären, um wiederholte SQL-Abfragen durchzuführen. Also, was hat er getan? Das Anwendungsstartereignis liest die gesamte Datenbank ein und konvertiert alles in Objekte im Speicher, die unbegrenzt gespeichert werden, bis der App-Pool wiederverwendet wird. Dieser Code war so langsam, dass das Laden von weniger als 2000 Mitarbeitern 15 Minuten dauern würde. Wenn Sie den App-Pool tagsüber versehentlich recycelt haben, kann dies 30 Minuten oder länger dauern, da bei jeder Webdienstanforderung mehrere gleichzeitige Neuladungen gestartet werden. Aus diesem Grund würden neue Mitarbeiter am ersten Tag der Kontoerstellung nicht in der Datenbank angezeigt und könnten daher in den ersten Tagen nicht auf die meisten internen Apps zugreifen und mit den Daumen drehen.

Die zweite Stufe des Pessimismus besteht darin, dass der Entwicklungsmanager ihn nicht berühren möchte, weil er befürchtet, abhängige Anwendungen zu beschädigen. Dennoch kommt es aufgrund des schlechten Designs einer so einfachen Komponente weiterhin zu sporadischen unternehmensweiten Ausfällen kritischer Anwendungen.

Niemand scheint das Sortieren erwähnt zu haben, also werde ich es tun.

Ich habe mehrmals festgestellt, dass jemand einen Bubblesort von Hand hergestellt hat, weil die Situation keinen Aufruf des bereits existierenden "zu ausgefallenen" Quicksort-Algorithmus "nicht erforderte". Der Entwickler war zufrieden, als sein handgefertigter Bubblesort gut genug für die zehn Datenzeilen funktionierte, die er zum Testen verwendet. Es ging nicht ganz so gut, nachdem der Kunde ein paar tausend Zeilen hinzugefügt hatte.

Ich habe einmal an einer App gearbeitet, die voller Code war:

 1 tuple *FindTuple( DataSet *set, int target ) {
 2     tuple *found = null;
 3     tuple *curr = GetFirstTupleOfSet(set);
 4     while (curr) {
 5         if (curr->id == target)
 6             found = curr;
 7         curr = GetNextTuple(curr);
 8     }
 9     return found;
10 }

Einfach entfernen found, nullam Ende zurückkehren und die sechste Zeile ändern in:

            return curr;

Verdoppelte die App-Leistung.

Ich musste einmal versuchen, Code zu ändern, der diese Edelsteine ​​in der Constants-Klasse enthielt

public static String COMMA_DELIMINATOR=",";
public static String COMMA_SPACE_DELIMINATOR=", ";
public static String COLIN_DELIMINATOR=":";

Jedes davon wurde im Rest der Anwendung mehrfach für unterschiedliche Zwecke verwendet. COMMA_DELIMINATOR hat den Code mit über 200 Verwendungen in 8 verschiedenen Paketen übersät.

Die große Nummer eins aller Zeiten, die mir in der Inhouse-Software immer wieder begegnet:

Die Funktionen des DBMS werden aus Gründen der "Portabilität" nicht verwendet, da "wir später möglicherweise zu einem anderen Anbieter wechseln möchten".

Lies meine Lippen. Für jede Inhouse-Arbeit: ES PASSIERT NICHT!

Ich hatte einen Kollegen, der versuchte, den Optimierer unseres C-Compilers zu überlisten und routinemäßig Code neu zu schreiben, den nur er lesen konnte. Einer seiner Lieblingstricks war das Ändern einer lesbaren Methode wie (Code erstellen):

int some_method(int input1, int input2) {
    int x;
    if (input1 == -1) {
        return 0;
    }
    if (input1 == input2) {
        return input1;
    }
    ... a long expression here ...
    return x;
}

das mögen:

int some_method() {
    return (input == -1) ? 0 : (input1 == input2) ? input 1 :
           ... a long expression ...
           ... a long expression ...
           ... a long expression ...
}

Das heißt, die erste Zeile einer einmal lesbaren Methode würde "return " werden und jede andere Logik würde durch tief verschachtelte terniäre Ausdrücke ersetzt. Wenn Sie darüber streiten wollten, dass dies nicht wartbar ist, hat er darauf hingewiesen, dass die Montageausgabe seiner Methode drei oder vier Montageanweisungen kürzer war. Es war nicht unbedingt schneller, aber es war immer winzig bisschen kürzer. Dies war ein eingebettetes System, bei dem die Speichernutzung gelegentlich eine Rolle spielte, aber es gab weitaus einfachere Optimierungen, die vorgenommen werden konnten, als dies, was den Code lesbar gemacht hätte.

Danach entschied er aus irgendeinem Grund, dass dies ptr->structElementzu unlesbar sei, und begann, all dies in (*ptr).structElementdie Theorie umzuwandeln, dass es auch lesbarer und schneller sei.

Lesen von lesbarem Code in unlesbaren Code für höchstens 1% Verbesserung und manchmal sogar langsameren Code.

In einem meiner ersten Jobs als vollwertiger Entwickler übernahm ich ein Projekt für ein Programm, bei dem Skalierungsprobleme auftraten. Es würde bei kleinen Datenmengen recht gut funktionieren, bei großen Datenmengen jedoch vollständig abstürzen.

Als ich mich vertiefte, stellte ich fest, dass der ursprüngliche Programmierer versuchte, die Dinge durch Parallelisierung der Analyse zu beschleunigen - indem er für jede zusätzliche Datenquelle einen neuen Thread startete. Er hatte jedoch einen Fehler gemacht, da für alle Threads eine gemeinsame Ressource erforderlich war, für die sie festgefahren waren. Natürlich sind alle Vorteile der Parallelität verschwunden. Darüber hinaus stürzten die meisten Systeme ab, um mehr als 100 Threads zu starten, nur um alle bis auf einen zu sperren. Meine bullige Entwicklungsmaschine war insofern eine Ausnahme, als sie in etwa 6 Stunden einen Datensatz mit 150 Quellen durchlief.

Um das Problem zu beheben, habe ich die Multithreading-Komponenten entfernt und die E / A bereinigt. Ohne weitere Änderungen fiel die Ausführungszeit für das 150-Quellen-Dataset auf meinem Computer unter 10 Minuten und auf dem durchschnittlichen Unternehmenscomputer von unendlich auf unter eine halbe Stunde.

Ich nehme an, ich könnte dieses Juwel anbieten:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    // Find out how many bytes our value uses
    // so we don't do any uneeded work.
    if (value & 0xffff0000)
    {
        if ((value & 0xff000000) == 0)
            tmp = 3;
        else
            tmp = 4;
    }
    else if (value & 0x0000ff00)
        tmp = 2;

    switch (tmp)
    {
        case 4:
            ISQRT_INNER(15);
            ISQRT_INNER(14);
            ISQRT_INNER(13);
            ISQRT_INNER(12);
        case 3:
            ISQRT_INNER(11);
            ISQRT_INNER(10);
            ISQRT_INNER( 9);
            ISQRT_INNER( 8);
        case 2:
            ISQRT_INNER( 7);
            ISQRT_INNER( 6);
            ISQRT_INNER( 5);
            ISQRT_INNER( 4);
        case 1:
            ISQRT_INNER( 3);
            ISQRT_INNER( 2);
            ISQRT_INNER( 1);
            ISQRT_INNER( 0);
    }
#undef ISQRT_INNER
    return root;
}

Da die Quadratwurzel an einer sehr empfindlichen Stelle berechnet wurde, hatte ich die Aufgabe, nach einer Möglichkeit zu suchen, sie schneller zu machen. Dieses kleine Refactoring reduzierte die Ausführungszeit um ein Drittel (für die Kombination aus Hardware und verwendetem Compiler YMMV):

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    ISQRT_INNER (15);
    ISQRT_INNER (14);
    ISQRT_INNER (13);
    ISQRT_INNER (12);
    ISQRT_INNER (11);
    ISQRT_INNER (10);
    ISQRT_INNER ( 9);
    ISQRT_INNER ( 8);
    ISQRT_INNER ( 7);
    ISQRT_INNER ( 6);
    ISQRT_INNER ( 5);
    ISQRT_INNER ( 4);
    ISQRT_INNER ( 3);
    ISQRT_INNER ( 2);
    ISQRT_INNER ( 1);
    ISQRT_INNER ( 0);

#undef ISQRT_INNER
    return root;
}

Natürlich gibt es sowohl schnellere als auch bessere Möglichkeiten, dies zu tun, aber ich denke, es ist ein ziemlich gutes Beispiel für eine Pessimierung.

Edit: Kommen Sie und denken Sie darüber nach, die abgewickelte Schleife war eigentlich auch eine ordentliche Pessimisierung. Durch die Versionskontrolle kann ich auch die zweite Phase des Refactorings vorstellen, die sogar noch besser abschnitt als die oben genannten:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1 << 30, root = 0;

    while (tmp != 0)
    {
        if (value >= root + tmp) {
            value -= root + tmp;
            root += tmp << 1;
        }
        root >>= 1;
        tmp >>= 2;
    }

    return root;
}

Dies ist genau der gleiche Algorithmus, wenn auch eine etwas andere Implementierung, also nehme ich an, dass er qualifiziert ist.

Dies kann auf einem höheren Niveau sein als das, wonach Sie gesucht haben, aber das Reparieren (wenn Sie erlaubt sind) beinhaltet auch ein höheres Maß an Schmerz:

Bestehen Sie darauf, einen Object Relationship Manager / eine Datenzugriffsschicht zu verwenden, anstatt eine der etablierten, getesteten und ausgereiften Bibliotheken zu verwenden (auch nachdem Sie darauf hingewiesen wurden).

Alle Fremdschlüsseleinschränkungen wurden aus einer Datenbank entfernt, da sonst so viele Fehler auftreten würden.

Das passt nicht genau zu der Frage, aber ich werde es trotzdem als warnende Geschichte erwähnen. Ich arbeitete an einer verteilten App, die langsam lief, und flog nach DC, um an einem Meeting teilzunehmen, das in erster Linie auf die Lösung des Problems abzielte. Der Projektleiter begann, eine Neuarchitektur zu skizzieren, um die Verzögerung zu beheben. Ich meldete mich freiwillig, dass ich am Wochenende einige Messungen vorgenommen hatte, die den Engpass auf eine einzige Methode isolierten. Es stellte sich heraus, dass bei einer lokalen Suche ein Datensatz fehlte, sodass die Anwendung bei jeder Transaktion zu einem Remote-Server wechseln musste. Durch Hinzufügen des Datensatzes zum lokalen Speicher wurde die Verzögerung beseitigt - Problem gelöst. Beachten Sie, dass die Neuarchitektur das Problem nicht behoben hätte.

Überprüfen Sie vor JEDER Javascript-Operation, ob das Objekt, mit dem Sie arbeiten, vorhanden ist.

if (myObj) { //or its evil cousin, if (myObj != null) {
    label.text = myObj.value; 
    // we know label exists because it has already been 
    // checked in a big if block somewhere at the top
}

Mein Problem mit dieser Art von Code ist, dass es niemanden zu interessieren scheint, was passiert, wenn er nicht existiert? Einfach nichts tun? Geben Sie dem Benutzer kein Feedback?

Ich bin damit einverstanden, dass die Object expectedFehler ärgerlich sind, aber dies ist nicht die beste Lösung dafür.

Wie wäre es mit YAGNI Extremismus. Es ist eine Form der vorzeitigen Pessimisierung. Es scheint, als ob Sie YAGNI jedes Mal, wenn Sie es anwenden, benötigen, was zu einem 10-fachen Aufwand beim Hinzufügen führt, als wenn Sie es am Anfang hinzugefügt hätten. Wenn Sie ein erfolgreiches Programm erstellen, werden Sie es wahrscheinlich brauchen. Wenn Sie es gewohnt sind, Programme zu erstellen, deren Leben schnell abläuft, dann üben Sie weiterhin YAGNI, denn dann nehme ich an, YAGNI.

Nicht gerade vorzeitige Optimierung - aber sicherlich falsch - wurde auf der BBC-Website aus einem Artikel über Windows 7 gelesen.

Herr Curran sagte, dass das Microsoft Windows-Team alle Aspekte des Betriebssystems überprüft habe, um Verbesserungen vorzunehmen. "Wir konnten die Abschaltzeit um 400 Millisekunden verkürzen, indem wir die Musik zum Herunterfahren der WAV-Datei leicht beschnitten haben.

Jetzt habe ich Windows 7 noch nicht ausprobiert, daher kann ich mich irren, aber ich bin bereit zu wetten, dass es andere Probleme gibt, die wichtiger sind als die Zeit, die zum Herunterfahren benötigt wird. Wenn ich die Meldung "Windows herunterfahren" sehe, wird der Monitor ausgeschaltet und ich gehe weg - wie profitieren mich diese 400 Millisekunden?

Jemand in meiner Abteilung hat einmal eine String-Klasse geschrieben. Eine Schnittstelle wieCString , aber ohne die Windows-Abhängigkeit.

Eine "Optimierung", die sie machten, war zu nicht mehr Speicher als nötig zuzuweisen. Anscheinend nicht erkannt, dass Klassen wie std::stringüberschüssigen Speicher zuweisen, ist, dass eine Folge von +=Operationen in O (n) Zeit ausgeführt werden kann.

Stattdessen erzwang jeder einzelne +=Aufruf eine Neuzuweisung, die wiederholte Anhänge in einen O (n²) Schlemiel the Painter-Algorithmus verwandelte .

Ein ehemaliger Mitarbeiter von mir ( eigentlich ein Soab ) wurde beauftragt, ein neues Modul für unser Java-ERP zu erstellen, das Kundendaten hätte sammeln und analysieren sollen (Einzelhandel). Er beschloss, JEDES Kalender- / Datums- / Uhrzeitfeld in seine Komponenten (Sekunden, Minuten, Stunden, Tag, Monat, Jahr, Wochentag, Bimester, Trimester (!)) Aufzuteilen, weil "wie sonst würde ich nach 'jedem Montag' fragen?"

Keine Beleidigung für irgendjemanden, aber ich habe gerade eine Aufgabe (Java) bewertet, die dies hatte

import java.lang.*;