Viele von Euch haben bestimmt schonmal einen Fetzen Code auf Geschwindigkeit optimiert. Funktionen "einlagern", Loop-Unrolling, Prozeduren mit Referenzen statt Funktionen verwenden sind nur einige Methoden, um die Laufzeit zu verringern. Zum Schluss vielleicht noch die Assembler-Keule schwingen. Das verringert die Wart- und Lesbarkeit aber oft ungemeint. Wie steht ihr zu dem Thema?

Wenn Source so langsam ist, dass ich ihn Optimieren muss, ist der Algo falsch, ansonsten hat mein Azubi falsch gearbeitet.

Mal im Ernst. Ich optimiere Source nur in dem Maße, dass eine ordnungsgemäße Fehlerkontrolle noch möglich und eine Wartbarkeit in Grundzügen noch gegeben ist.

Wenn Source nicht selbsterklärend dokumentiert ist, gehört dem Autor eine Tracht Prügel, speziell, wenn der Source so aussieht, als ob der Fetzen vom Autor noch nicht am nächsten End vorüber ist ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hallo!

Ich denke, da muss man jedes Mal von neuem abwägen. Ich persönlich habe eine wirklich "verunstaltende Optimierung" erst einmnal gemacht. Dabei ging es um ein C-Programm, welches Elektronenbahnen durch elektrostatische Linsen in einer auf Potential liegenden Röhre berechnen sollte. Das genhemigte sich zur Berechnung einer einzigen Konfiguration schonmal zwei Stunden (je nachdem, wie gut das Verfahren konvergierte).

In diesem Fall war eine solche "Todoptimierung" schon Sinn, denn zum einen würde das Programm bis zum Ende des Projektes oft eingesetzt werden, zum anderen hinterher nicht mehr verwendet, sodass Wartbarkeit praktisch unwichtig war.

Dagegen gibt es auch im Institut geschriebene Libraries, welche ebenfalls oft benutzt werden und aufwändige Berechnungen durchführen, welche aber wahrscheinlich bis zum Ende aller Zeiten verwendet werden. Die kann man natürlich nicht Tod optimieren, vor allem auch deshalb, weil wechselnde Personen daran arbeiten, die alle den Code verstehen müssen.

Insgesamt kann man nicht sagen, dass so etwas gut oder schlecht. Das muss man in jedem Einzelfall entscheiden. In obigen Beispielen kam auch nicht zum tragen, ob die Optimierung nicht mehr Zeit in Anspruch nimmt als sie hinterher spart. Kann auch vorkommen

Grüße
Christian

Hallo!

Es gibt Leute, die investieren 5h und optimieren Routinen, sodaß sie von 10 Sekunden Laufdauer auf 3 Sekunden kommen. Das klingt nicht schlecht, nicht wahr? Wenn man dann aber sieht, daß es nur eine Subroutine ist, und das Programm vorher 10 Minuten lang auf Ergebnisse vom SQL-Server wartet, macht es nicht mehr so richtig Sinn. Krümel wegräumen, aber den Kuchen auf dem Boden liegen lassen...

Cu,
Udontknow

Natürlich muss man vorher mit dem Profiler schauen, ob sich eine Optimierung lohnt.

Also, wer eine Routine mit den letzten verbleibenden Tricks um ein paar Prozentpunkte schneller macht, ist ein Hobbyprogrammierer, was nichts mit dem Können zu tun hat, sondern mit dem Einsatzgebiet seiner Künste (z.B.: Programmierwettbewerbe à la FastCode).

Wieso? Weil es in den seltensten Fällen auf marginale Verbesserungen eines Verfahrens ankommt, sondern auf die Verbesserung des Verfahrens. Beispiel Primzahltest. Es gibt Tests, die machen das in linearer Zeit O(n), und dann gibt es welche, die schaffen das in O (log log n). Da kann ich meinen linaren Algorithmus optimieren, so viel ich will, das bringt nix.

Es kommt doch in erster Linie auf das ausgewählte Verfahren an. Wenn das vom Aufwand stimmig ist, dann ist die Welt in Ordnung. Es gibt das berühmte Beispiel von einem 1Mhz Microcontroller, der mit Quicksort sortiert, und einem 7Ghz PRozessor, der die gleiche Liste mit Bubblesort in die sortieren soll. Die 1Mhz Gurke ist -eine lange Liste vorausgesetzt- immer schneller.

Was Benny meint, ist vollkommen richtig: Wer mir eine zu Tode optimierte Funktion mit stolzgeschwellter Brust vorsetzt, darf als Dankeschön mit seiner Zahnbürste das Büro schrubben .

Das Allerwichtigste beim Coden sind die beiden Grundregeln:
1. Keep it simple
2. Use the right techniques

Schliesslich muss ein Programm in erster Linie laufen. Stabil. Und dann muss es erweiterbar (also wartbar) sein. Auch nach Jahren.

Soso. Stell dir vor du bietest einen SQL-Server an, der nur 25% der Geschwindigkeit der Konkurrenz erreicht (bei Einsatz der effizientesten Algorithmen), aber du kannst dich damit brüsten, dass Euer Source-Code so ordentlich und gut lesbar ist. Ich glaube, da bist du nicht lang im Geschäft. Oder ein Spiel, was dann halt bei dir hässlicher aussieht auf gleichem Rechner. Ein Quicksort ist auch nicht immer schneller als ein Bubble-Sort. Wenn du z.B. nur 5 Zahlen zu sortieren hast, das aber einige millionen mal, dann kann Quicksort einen höheren Overhead haben und langsamer sein.

Ich habe jetzt eher an so Sachen wie (muss jetzt nicht unbedingt schneller sein) z.b.



anstatt



gedacht, was bei dummen Compilern und bestimmten Prozessoren Geschwindigkeit bringt.

@alzaimar: Mag ja sein, dass es in vielen Fällen bessere Verfahren gibt. Aber irgendwann ist man auch da am Ende und dann kann man nur noch an der Implementation schrauben. Und je nach Anwendungsgebiet macht es dann schon Sinn, auch einen etwas weniger gut wartbaren Code zu erzeugen. In meinem Fall war das z.B. so. Denn dieses Programm musste nicht nach Jahren wartbar sein

Ich halte nichts von diesen ehernen Programmiererregeln, die blind auf jeden Fall angewendet werden sollen. Eine Einzelfall-Entscheidung ist meist sinnvoller.

Ich will es mal so sagen : Code-Optimierung zum Beschleunigen in einem Delphi-Programm, das ist nur wichtig bei Programmen, die kaum Festplattenzugriffe machen und gleichzeitig komplizierte langwierige Berechnungen machen, siehe Christan S. Da schlägt das zu Buche. Udontknow hat es ja schon gesagt : man jage jeder Nanosekunde nach und dann kommt ein SQL - Design-Fehler und macht alle "Optimierungen" komplett überflüssig.

So was wie : inc (i); sehe ich auch nur ungern. Was soll sowas bringen ? Die Lochkartenzeiten sind schon vorbei und der Compiler optimiert sowieso, wo er nur kann.  i := i + 1; weiß jeder. Deshalb steht für mich die Lesbarkeit des Quelltextes an erster Stelle.

Aber an der Frage fehlt noch was sehr wichtiges : wie sieht die Programmlogik für schnelles Programm eigentlich aus (also nicht nur DB-mäßig) ? Ich hatte letztens folgenden Effekt : größeres Stringgrid wird aus DB gefüllt. Dauer 1-2 Minuten. Wäre auf jeden Fall noch vertretbar gewesen. Jetzt wollte ich aber wissen, wie lange der reine Füllvorgang dauert und habe die Anzeige der Werte im Grid unterdrückt. Hätte mit geringfügig schnellerem Programmlauf gerechnet, darum gings aber nicht.

Start-Button für Füllvorgang gedrückt, auf der Uhr den Sekundenzeiger gesucht und wollte dann auf die Showmessage ('fertig') warten. Aber die war schon da ! Tja, habe gedacht, da läuft wohl was verkehrt.

Aber Pustekuchen, da war alles richtig. Nachdem das Stringgrid wieder sichtbar gemacht war habe ich nochmals die Zeit gestoppt : wieder 1-2 Min. je nach Datenmenge. Ein schlichtes Stringgrid.Hide und dann Stringgrid.Show hatte die Laufzeit dann tatsächlich auf max. 2 Sek. reduziert. !! Das nenne ich doch mal Optimierung.

Hat ein Stringgrid denn kein BeginUpdate/EndUpdate?

BeginUpdate ? Was soll das machen ? Ist auch egal, mein Beispiel geht in die Richtung von Alzaimars Beitrag. Daß es eben nichts nützt an Randsymptomen rumzuschrauben, wenn das große Ganze falsch angelegt ist. Der Witz bei mir war ja nur, daß ich dasselbe Verfahren wie vorher anwende, eben nur marginal anders. Und der Quelltext ist noch genauso schön zu lesen wie vorher. Und ich hatte ja den DB-Source optimieren wollen und der war gut genug.

@spaceguide: Ausnahmen bestätigen die Regel. Ich sagte ja: "in den seltensten Fällen". Nächtes Mal genauer lesen, bitte. Und wenn Du dir das Kochbuch zum SQL-Server durchgelesen hättest, wüsstest Du, das der Server nur mit Wasser kocht, keine hässlichen Optimieren beinhaltet und einfach nur gute und schnelle Algorithmen und Verfahren implementiert. Das ich am Ende, wenn alles läuft, den einen oder anderen Algorithmus gut dokumentiert und nachvollziebar optimiere, versteht sich ja wohl von selbst. Aber wenn ich mich krankoptimiere, dann hab ich was falsch gemacht (oder ich leg es drauf an). Zeig mir mal einen ordendlichen, kompakten und effizienten Code, aus dem Du noch 75% rausholst. Nie und nimmer ( ). Insofern ist dein Beispiel Käse. Ich bekomme mit ASM heutzutage keine 25% mehr aus dem Code heraus. Punkt. Unsere DB-Engine ist sauschnell und kommt ohne blödsinnige Optimierungen heraus. Betonung auf 'blödsinnig'. Ach, und sie _ist_ konkurrenzfähig.

@Christian: Regeln sind zum brechen da. Ich jedenfalls verlange von meinen Codern, das sie sich so lange nur an diese beiden Regeln halten, bis sie ordendlichen, fachlich fundierten und performanten und lesbaren Code im Schlaf erzeugen. Bisher hat das noch immer gelangt.
Beispiel für nicht blodsinnige Optimierung (obwohl schwerer lesbar):
Statt sequentieller Zugriffe auf ein Array per Index,
darf man ruhig Pointerarithmetik benutzen,
(wenns was bringt, kommt auf den Teil in der Schleife an)
Anstatt eine Formel in 20 Schritten zu implementieren, reicht es, sie zusammenfassend hinzuschreiben. Hauptsache dokumentiert. Usw. Bei endlosen jumptabellen oder kryptischen castings reicht es uns auch.

An Euch beide sei mal ein Denkanstoss gerichtet: Ich schrieb von 'seltensten Fällen'. Das schließt also Fälle nicht aus, bei denen optimiert werden muss. Beide widersprecht Ihr mir, indem Ihr als Argument eben eine diese 'seltensten Fälle' anbringt. Ja was denn nun? Entweder widersprechen, oder zustimmen. Beides gleichzeitg geht nicht. Obwohl, ihr schafft das . Nicht schlecht.

@hansa: inc(i) ist Geschmacksache. Ich find das eindeutig lesbarer als i:=i+1. Aber es gilt: 2 Menschen, 2 Meinungen. Und was Du über dein Stringgrid berichtest, ist imho keine 'Optimierung'. Da geht es ums ordendliche Programmieren. Ich muss ja nicht gleich den gesunden Menschenverstand vor der Tür lassen, bloss weil Regeln befolgt werden müssen. Wir hatten neulich auch so einen ähnlichen Fall. Da wurde dann kurzerhand das Programm umgestrickt und ordendlich gemacht --> von 5 sec auf 400 ms pro Ladevorgang.

@hansa
möchtes du damit sagen, das die grafik ausgabe im programm sehr viel zeit in anspruch nimmt ?
und sich dein beispiel auch auf andre andwendung anwendet ?
ich habe da eine playliste und ein selbst geschriben mediaplayer immer wenn ich jetzt die playliste lade dauert das einige zeit(k.a wie lange) weil ich halt erst alles in eine TSTringList lade und dann in eine ListBox anzeige wobei einzelde einträge in andren Farben angezeigt wird(ist aber variabel).

muss ich einfach mal testen bei gelegheit *G*

Zitat:

Das Allerwichtigste beim Coden sind die beiden Grundregeln: 1. Keep it simple 2. Use the right techniques Schliesslich muss ein Programm in erster Linie laufen. Stabil. Und dann muss es erweiterbar (also wartbar) sein. Auch nach Jahren.

da stimme ich 100%ig überein - siehe Signatur. Das das Stringgrid ausblenden und enblenden die Füllprozedur wesentlich beschleunigt habe ich auch schon festgestellt... wichtig in dem Zusammenhang ist auch die Funktion disablecontrols bei querys (ok bei DBGrids und die benutzt hansa ja nicht) ...

alzaimar hat folgendes geschrieben:

An Euch beide sei mal ein Denkanstoss gerichtet: Ich schrieb von 'seltensten Fällen'.

Dein Posting enthielt soviele Pauschalaussagen (fing ja schon damit an, alle in einen Topf zu werfen, die auch für Kleinigkeiten optimieren), dass ich das in dem einen Absatz wirklich übersehen haben muss.

@Alzhaimer : Code ist Code, auch das Programm selbst ! Show und Hide hat genügt um einen Geschwindigkeitsfaktor > 50 hinzukriegen. Es war aber auch eher das hier gemeint :

Hansa hat folgendes geschrieben:

Aber an der Frage fehlt noch was sehr wichtiges : wie sieht die Programmlogik für schnelles Programm eigentlich aus ?

Ja und Inc ist in der Tat Geschmackssache, es gibt aber einige die das verwenden, um vermeintlich eine halbe Nanosekunde einzusparen. Man kann durch solch übertriebene Sachen auch den Compiler daran hindern etwas selber zu optimieren. i := i + 1 finde ich halt besser.

@Mimi : es war eindeutig das Zeichnen des Grids ! Trotz dauernden lesens aus der DB ist nicht das das Nadelöhr gewesen, sondern das Grid ! Seitdem beäuge ich das grafische Zeichnen von Windows etwas mißtrauisch.

Optimierung ist halt so eine Sache. Aber selbst bei der DB war es noch nicht nötig da groß Indexe usw. von Hand anzulegen. Die muß natürlich auch logisch gut angelegt und im Programm angesprochen werden, siehe Stringgrid. Und man muß auch richtig testen. Gerade die DB-Sachen, zumindest wenn etwas wichtiges geändert wurde, die teste ich immer im Netzwerk !

Edit : Mimi, ehe das falsch verstanden wird : eine Stringliste zu füllen ist dasselbe wie in meinem Grid. Wenn aber die gefüllte Stringliste Element für Element in der Listbox angezeigt wird, dann würde mich ein ähnlicher Effekt nicht wundern ! Der Trick ist : Hide,Listbox/Stringgrid im HINTERGRUND füllen, Show.

Eine Physikarbeit würde ich aber definitiv nicht in Pascal schreiben. In Punkto Geschwindigkeit ist Delphi nicht optimal. Es gibt zwar Websites, die das versuchen zu widerlegen, jedoch gibt es imho genügend Gründe, wieso man mit Pascal eher die langsameren Codes schreibt.

Hier noch drei Grundregeln fürs Optimieren: 1. Professionelle Libraries verwenden 2. Die richtigen Algorithmen auswählen 3. Profiling

delfiphan hat folgendes geschrieben:

Eine Physikarbeit würde ich aber definitiv nicht in Pascal schreiben.

Das Programm war in C geschrieben. Da fällt mir übrigens eine weitere gute Möglichkeit der Optimierung ein: Den richtigen Compiler verwenden. Der Intel-Compiler ist wirklich cool Ich gebe zu, dass es da bei Delphi wenig Auswahl gibt

ein wenig off-topic: Alleine schon, weil viele vorhandene Codes aus diesem Bereich in C(++) geschrieben sind, wäre es selten wirtschaftlich, solche Anwendungen in einer anderen Sprache zu schreiben.

professionelle Libraries: Japp, da kann ich nur zustimmen. Das macht viel aus.

@delfiphan
ich habe in einem "uralten" buch mal gelesen delphi(pascal?) soll sogar etwas schnell sein als c. Wenn du direkt mit WinApi arbeites müste das doch überall gleich sein oder ?
ob nun in c, c++, delphi, pascal,... dürfte dann egal sein

@delfiphan: Das Delphi langsamen Code erzeugt, haben wir in den Threads zur Primzahlenfunktionsoptimierung widerlegt bzw. in Frage gestellt. Die nehmen sich doch alle nicht mehr viel, die Compiler mein ich...

Die Diskussion ist wieder da, wo sie hingehört: Bei der Frage, wie schnelle Programme strukturiert sein sollen.
Vielleicht folgender Denkansatz (So bekommt man performante Anwendungen, frei nach dem Al'Zai-Mar) :
1. Prinzip der zentralen Speicherung (Datenmodule).
Hier meine ich mit Datenmodul erstmal eine zentrale Unit, die semantisch Zusammenhängende Eigenschaften eines Subsystems verwaltet. Das kann eine Klasse, ein TDatamodule oder sonstwas sein. Ich kann dan von allen Subsystemen zentral darauf zugreifen. Wenn ich es richtig anstelle, erspare ich mir damit überflüssige Datentransfers. Natürlich ist hier nicht die Überhabe eines Objekt(pointer)s als Parameter. Ich meine die eher abstrakte Verschiebung bzw. Umschichtung von Daten. Hmm. Schwer zu erklären. Wenn man sich an das Prinzip hält, merkt man schnell, das man sehr elegant und performant damit arbeiten kann.

2.Prinzip der separierten Visualisierung.
Ein zweiter Pferdefuss ist die Visualisierung von Daten. Auf einem komplexen Formular reagieren die datensensitiven Elemente (Controls) miteinander auf vielfältige Art und Weise: Beim Ankreuzen einer Checkbox sollen Controls an/abgeschaltet, beim Bewegen durch eine Liste müssen Eingabefelder aktualisert, beim Befüllen eines Grids soll immer der aktuelle Inhalt angezeigt werden etc. Was während der Eingabe wichtig und nützlich ist, bremst beim Befüllen der Daten ungemein (wie hansa schon am eigenen Code festgestellt hat).
Abhilfe schaffen kleine Tricks: Wenn ich die Interaktion der Elemente während des Befüllens ausschalte, erziele ich gewaltige Performancesprünge. Dazu reicht es z.B., einen Flag 'Initializing' zu pflegen. Sämtliche Events werden ignoriert, wenn der Flag gesetzt ist.

3.Prinzip der optimalen Verfahren.
Was bringt eine sauschnelle Visualisierung, wenn die Anwendung mit Bubblesort sortiert? Aufwandsabschätzungen ('Big Oh') sollten jedem Entwickler in Fleisch und Blut übergehen. Die Grundalgorithmen sowie Basisdatentypen müssen im Schlaf auskodiert werden können. Hier greife ich mal die Prämisse der 'professionellen Libraries' auf, damit ist eigentlich alles gesagt. Die iterative Suche (For i:=0 to n-1) ist bei dynamischen Listen zu vermeiden. Alle gängigen Probleme (NP-Komplette ausgenommen) lassen sich in maximal quadratischem Zeitaufwand O(n^2) realisieren (Ausnahme: Matrizenmultiplikation). Wer in seiner Anwendung eine höhere Komplexität entdeckt, hat Nachbesserungsbedarf. Das geht übrigens schneller, als man denkt: Wer eine Suche iterativ auskodiert und dann mehrere ineinander verschachtelte Suchen durchführen muss, ist schnell bei einer hohen Komplexität (O(n^s)) angelangt Wenn die Suchfunktion als Hash-Dictionary implementiert wird, bleibt der Zeitaufwand minimal.

.... (Meine Tochter ruft)

(Liste kritisieren und/oder fortführen)