it-swarm.com.de

Wie nennt man das, wenn man die Big O-Ausführungszeit einer Funktion ändert?

Angenommen, ich habe eine Funktion, die eine Datenbank in O(n^2) Zeit sortiert. Ich möchte es umgestalten, damit es in O(n log(n)) Zeit ausgeführt wird, und dabei werde ich die grundlegende Art und Weise ändern, in der die Operation ausgeführt wird, während die Rückgabewerte und Eingaben gleich bleiben.

Wie nenne ich diese Refactoring-Aktivität?

"Speeding-up-ifying" scheint nicht ganz richtig zu sein, da Sie einen Algorithmus schneller machen können, ohne die große O-Geschwindigkeit zu ändern, mit der er ausgeführt wird.

"Vereinfachen" scheint auch nicht richtig zu sein.

Wie nenne ich diese Aktivität?

Aktualisieren

Die beste Antwort, die ich finden konnte, ist Reduzierung der asymptotischen Zeitkomplexität.

19
Code Whisperer

Es wird normalerweise "Leistungsoptimierung" genannt, aber ich würde es nicht "Refactoring" nennen, da sich dieser Begriff normalerweise auf Änderungen im Code bezieht, die dies nicht tun ändere sein sichtbares Verhalten . Und eine Änderung in Big-O ist definitiv etwas, das ich als sichtbare Änderung bezeichnen würde.

dabei werde ich die grundlegende Funktionsweise der Operation ändern

In diesem Fall ist Ihre Optimierung ein Umschreiben dieser Funktion. Nicht jede Optimierung, auch wenn sie "Big-O" ändert, ist notwendigerweise eine Neufassung, manchmal sind nur kleine Änderungen erforderlich, um eine solche Verbesserung zu erzielen, aber selbst dann zögere ich, den Begriff "Refactoring" dafür zu verwenden, weil es neigt dazu, einen falschen Eindruck über die Art der Änderung zu vermitteln.

EDIT: Ich habe Fowlers Refactoring-Liste überprüft, und unter diesen ~ 100 benannten Refactorings heißt das allerletzte "Ersatzalgorithmus" . Wenn wir dies als kanonische Referenz nehmen, gibt es eine kleine Grauzone, in der eine Optimierung der beschriebenen Form als spezielle Art des Refactorings bezeichnet werden kann (aber meiner Meinung nach keine typische). Beachten Sie auch, dass Fowlers Ziel bei allen Refactorings immer darin bestand, das Design zu verbessern, wobei der Schwerpunkt auf der Wartbarkeit und Entwickelbarkeit des vorhandenen Codes lag, ohne ihn neu zu schreiben, und eindeutig nicht auf der Leistungsoptimierung.

44
Doc Brown

Ich glaube nicht, dass es einen Standardbegriff gibt, ein häufig verwendeter ist Optimieren obwohl Eine Verbesserung oder Beschleunigung wäre auch richtig, wenn klargestellt würde, dass es sich um Codeänderungen und nicht um Hardware handelt Änderungen.

13
ichantz

Wie andere gesagt haben, ist "Optimieren" der allgemeine Begriff für die Verbesserung der Leistung eines Algorithmus. Optimieren bedeutet jedoch oft, konstante Faktoren zu verbessern. Wenn ich kurz und deutlich sagen wollte, dass ich die asymptotische (Zeit-) Komplexität reduziert habe, würde ich sagen, dass ich "die asymptotische Leistung verbessert" habe. Manchmal wird dies als "Verbesserung der Skalierung" beschrieben, aber dies ist heutzutage besonders zweideutig.

Warnung: Das Reduzieren der asymptotischen Zeitkomplexität ist nicht unbedingt dasselbe wie das Optimieren in einem praktischen Kontext. Oft werden asymptotisch nicht optimale Algorithmen verwendet, da das Programm im Bereich der Eingaben tatsächlich den weniger optimalen Algorithmen ausgesetzt ist, die eine bessere Leistung erbringen.

Es wird kontextabhängig sein.

"Beheben eines quadratischen Laufzeitleistungsfehlers" ist normalerweise das, was ich sehe. Ob dies jedoch behoben werden muss (eine Codeänderung), ist kontextabhängig.

Beachten Sie, dass Datenbanken viele Tools zur Verbesserung der Zeitkomplexität bieten. Um beispielsweise die besten N Ergebnisse aus einer Datenbank zu erhalten, sagen Sie es einfach. Bei der Umwandlung von ineffizientem Kludge in einen integrierten optimierten Aufruf erscheint eine Erklärung überflüssig.

Der Grund, warum ich einen Algorithmus mit quadratischer Laufzeit für eine Codeüberprüfung (Diskussion) halte, ist nicht so sehr, weil er langsam ist (langsam ist relativ; quadratisch ist schnell im Vergleich zu exponentiell), sondern weil die menschliche Intuition (wie Ihre Kunden oder Programmierkollegen) fühlen sich von Natur aus mit einer Softwarefunktionalität unwohl, die aufgrund der Vermischung der Erwartungen aus dem Alltag zu weit von der linearen Laufzeit abweicht.

Viele Kundenbeschwerden über die Softwareleistung fallen in diese beiden Kategorien:

  • Das gesamte System (Software und Hardware) wurde basierend auf der geschätzten Nutzung spezifiziert. Letzte Woche läuft alles gut, eine bestimmte Funktionalität hat weniger als 5 Sekunden gedauert. Diese Woche nach der Installation eines Updates dauert dieselbe Funktionalität länger als 1 Minute.

    • Dies ist ein Vergleich mit einer zuvor gemessenen Leistung. Der Kunde hält die zukünftige Leistung an einem absoluten Maßstab einer menschlichen Zeitskala (von Sekunden bis Minuten).
  • Ich habe 100 Jobs an das System gesendet. Warum dauert die Bearbeitung 400-mal so lange wie für einen einzelnen Auftrag?

    • Der Kunde erwartet eine lineare Bearbeitungszeit. Tatsächlich kann der Kunde nicht verstehen oder akzeptieren, dass es Aufgaben gibt, die langsamer als linear sind.

Aus diesem Grund betrachtet ein Kunde die Ausführungszeit als Fehler, wenn beide zutreffen:

  • Langsamer als linear
  • Auffällig (d. H. Fällt bei typischen Aufgabengrößen in den menschlichen Zeitbereich (länger als Sekunden oder Minuten))

Berechtigte Argumente, die erklären, dass ein quadratischer Laufzeitalgorithmus kein Problem darstellt (d. H. Keine Codeänderung verdient):

  • Die Größe der Aufgabe, die normalerweise von dieser quadratischen Laufzeitfunktion ausgeführt wird, ist etwas begrenzt
  • Angesichts des typischen Größenbereichs ist die tatsächliche (absolute) Ausführungszeit immer noch klein genug, um verworfen zu werden
  • Wenn ein Benutzer tatsächlich versucht, eine Aufgabe zu senden, die groß genug ist, um wahrgenommen zu werden, erhält der Benutzer eine Warnmeldung über die lange Laufzeit
  • Die Benutzer des Systems sind alle Experten, daher wissen sie, was sie tun. Beispielsweise sollten Benutzer einer API das Kleingedruckte in der API-Dokumentation gelesen haben.

Viele Algorithmen, die für die typische Anwendungsentwicklung nützlich sind, sind tatsächlich langsamer als linear (meistens O (N log N), wie beim Sortieren), daher wird große Software tatsächlich versuchen, dies zu umgehen, indem nur der relevante Teil des Daten oder verwenden Sie Histogramm (statistische) Filtertechniken, die einen ähnlichen Effekt erzielen.

Dies gilt für Softwarekunden. Wenn Sie jedoch die Benutzer einer Softwarebibliothek oder einer API-Funktion ebenfalls als "Kunden" betrachten, gilt die Antwort weiterhin.

5
rwong

Wenn der ursprüngliche Algorithmus korrekt implementiert wurde (oder Fehler, die irrelevant waren), dann "Ändern des Algorithmus" oder "Ersetzen des Algorithmus", da solche Änderungen bedeuten, dass Sie genau das tun; Ersetzen des zuvor verwendeten Algorithmus durch einen Algorithmus mit unterschiedlicher zeitlicher Komplexität.

Wenn die Komplexität der vorherigen Zeit auf einen Fehler in der Implementierung zurückzuführen war (z. B. wenn Sie versehentlich den Startpunkt einer inneren Schleife in einer Sequenz zurückgesetzt haben, sodass das, was hätte sein sollen, O(n)) wurde Auf2)) dann "Behebung eines quadratischen Kostenfehlers" oder ähnlich.

Es gibt eine Überlappung, da in einem solchen Fall die Auswirkung auf den Code dieselbe ist, wenn Sie von Anfang an wissen, dass die Arbeit in O(n) Zeit und dem O (n) ausgeführt werden kann2) Zeit war ein Fehler, oder wenn Sie ihn zuerst absichtlich in O (n2) Zeit und erkannte dann, dass es immer noch korrekt funktionieren würde, ohne den Startpunkt zurückzusetzen, und ersetzte so einen O (n) durch einen O(n) - Algorithmus)2) einer.

2
Jon Hanna

Geschwindigkeitsoptimierung um eine Größenordnung. Obwohl dies eine mathematisch falsche Sprache ist, vermittelt sie am besten die Idee der Ordnung geändert werden.

Verbesserte die Skalierbarkeit. hörte auch.

1
Joop Eggen