Ich habe schon einiges in Delphi programmiert, aber bisher mich nie mit Optimierung auseinandergesetzt. Da sind nun so einige Fragen aufgetaucht:
1. Wie kann ich kleine Programme schreiben? Eine leere Form ist ja bereits 359 KB gross (Delphi 7)... Aber Achtung: Ich möchte keine Packer wie UPX benutzen, sondern das direkt in Delphi realisieren
2. Wie optimiere ich die Programme in Sachen Geschwindigkeit? Ich bitte um möglichst allgemeine Tipps, Beispiele sind aber gern gesehen
3. Wie optimiere ich den Speicherverbrauch? Welche Grundregeln sind zu befolgen, was sind absolute No-gos?
Weitere werden folgen

MfG Z4ppy

um das Projekt kleiner zu machen, kannst du nonVCL-Programmierung nutzen. Ist halt nur was mehr arbeit und man benötigt ja auch nicht unbedingt alle standardmässig eingebundenen units...
was man auch vermeiden sollte sind globale variablen. Soweit es geht lokale variabeln verwenden oder als private deklaration der Form erzeugen

1) Wie schon geschrieben wurde, ist der Verzicht auf die VCL definitiv nötig, wenn man kleine Echsen haben möchte.

2) Dazu gibt es keine allgemein gültigen Aussagen, da kommt es auf den speziellen Fall an, wie man an der Performance-Schraube drehen kann.

3) Alle Objekte, Variablen, Handles, etc. nur so lange im Speicher / in Benutzung halten, wie es unbedingt nötig ist.
Und da wären wir auch schon wieder bei Deiner zweiten Frage und dem "speziellen Fall". Wenn Du so viel wie möglich im Speicher hältst, läuft die Anwendung schneller als wenn sie z.B. alles immer und immer wieder von der Festplatte laden muss. Da ist es eine Gratwanderung zu entscheiden, was man wie handelt. Entweder auf Geschwindigkeit optimieren oder auf Speicherverbrauch (den goldenen Mittelweg gibt es selbstverfreilich auch).

Danke ihr beiden, das nonVCL-Tutorial werd ich morgen mal durcharbeiten...

Es gibt doch sicher noch andere Sachen, die die Geschwindigkeit eines Programms beeinträchtigen, als das Laden von der Festplatte statt ausm Speicher... Ich denke da an Algorithmen, z.B. Verschlüsselungen oder Hash-Verfahren Auch die können sehr langsam oder sehr schnell sein, woran liegt es dort hauptsächlich?

MfG Z4ppy

Zitat von Z4ppy:

Ich denke da an Algorithmen, z.B. Verschlüsselungen oder Hash-Verfahren Auch die können sehr langsam oder sehr schnell sein, woran liegt es dort hauptsächlich?

An der optimalen Optimierung, im speziellen Fall. Es gibt in solchen Sachen kein klares "do it like this, and you beat 'em all". Inline-Routinen und -Assembler können helfen, müssen aber nicht schneller sein als der vom Delphi-Compiler erzeugte Maschinen-Code. Alles andere ist zu speziell um eine klare Aussage zu treffen.

Zitat von Z4ppy:

Es gibt doch sicher noch andere Sachen, die die Geschwindigkeit eines Programms beeinträchtigen, als das Laden von der Festplatte statt ausm Speicher... Ich denke da an Algorithmen, z.B. Verschlüsselungen oder Hash-Verfahren Auch die können sehr langsam oder sehr schnell sein, woran liegt es dort hauptsächlich?

Das ist von Fall zu Fall verschieden, da gibt es nichts allgemeines. Ein Hash Algorithmus funktioniert anders wie ein Verschlüsselungs Algorithmus.

Und warum stört dich die Größe der Exe-Datei? Bei heutigen Speichermedien ist das absolut irrelevant. Die zusätzlihe Arbeit lohnt nicht wirklich. Aber falls du noch ein Tutorial suchst: http://delphitutorials.michael-puff.de .

Zitat von Luckie:

...Und warum stört dich die Größe der Exe-Datei? Bei heutigen Speichermedien ist das absolut irrelevant...

Und das kommt vom Ober-nonVCL-Guru. Optimierung hat mit dem Speicherplatz mittlerweile absolut nichts mehr zu tun. Bei Online (also Downloads etc.) siehts vielleicht anders aus, sofern man mit ein paar Handgriffen die Größe von 100 MB auf 10 MB reduzieren kann. Aber von 1 MB auf 100 KB mit Klimmzügen ala nonVCL runterzuschrauben macht keinen Sinn.

Ich habe mich mit nonVCL beschäftigt, weil ich wissen wollte, wie Windows funktioniert. Natürlich war anfangs auch der Ehrgeiz da, die Exe möglichst klein zu bekommen. Aber produktiv oder wirtschaftlich ist es nicht und für größere Projkete fast gänzlich ungeeignet. Bei kleinen Tools kann man durchaus auf die VCL verzichten.

Zitat von Z4ppy:

Wie optimiere ich den Speicherverbrauch?

Die größten Speicherverbrauchseinsparungen (ich nehme an du meinst hier Arbeitsspeicher) ergeben sich durch gute Logik im Algorithmus! Deshalb kann man da auch keine pauschale Antwort geben...

Um mal ein Beispiel zu nennen: Programmiert wird ein Hopfield-Neuronales-Netz. Das heißt jedes Neuron ist mit jedem verbunden. Der unbedarfte Programmierer würde also z.B. bei 100 Neuronen entweder 10.000 oder 9900 Verbindungen speichern müssen, je nachdem wie weit er denkt. Tatsächlich muss man aber aufgrund der besonderen Eigenschaften eines Hopfield-Netzes nur die Hälfte, nämlich 4950 Verbindungen speichern. Diese Optimierung um die Hälfte (!!!) ergibt sich allein durch eine Optimierung der Logik, nicht durch irgendwelche Programmiertricks!

Also ich habe die Erafhrung gemacht, dass man weniger Speicher meistens mit mehr Rechenaufwand bezahlt, und wenig Rechenaufwand mit viel Speicher. Es gilt einen Kompromiss zu finden. Z.B. habe ich mal einen Leveleditor für ein Spiel (nicht von mir) geschrieben. Bei manchen Levels sind sehr, sehr viele Objekte zu zeichnen. Deshalb zeichne ich nur neu, wenn sich etwas ändert, dann lege ich diesen Layer in einem Bitmap im Speicher ab. Das resultiert zwar in einem höheren Speicherverbrauch (Bitmaps sind absolute Speicherfresser), aber lässt eine annehmbare Geschwindigkeit zu.

Was die Geschwindigkeitsoptimierung angeht: Pauschal kann man sagen, je weniger Anweisungen, desto höhere Geschwindigkeit. Dabei ist auch zu beachten, dass nicht jede Operation gleich schnell ist. Eine Multiplikation ist z.b. schneller als eine Division, manchmal lohnt es sich also, Algorithmen so umzuformen, dass man andere Operationen benutzen kann. Wenn du ein absoluter Perfromancefreak bist, kannst du bestimtme Funktionen auch in Inline-Assembler implementieren. Der damit verbundene Aufwand ist aber nur in sehr seltenen Fällen sinnvoll, wenn schon alles andere perfekt optimiert ist. Meistens bringen "gröbere" Optimierungen mehr.

Bei Parametern > 4 Byte sollte man, wenn möglich, die Direktive const verwenden. Dadurch spart man sich erstens die Rechenzeit zum Kopieren der Daten auf den Stack, spart Speicher, und beugt einem Stacküberlauf vor. Vor allem bei großen Datentypen wie beispielsweise Strings ist das sehr sinnvoll.

Wenn man Dateien von der Festplatte liest, ist es sinnvoll, die Datei in größeren Blöcken (gepuffert) einzulesen, weil die Festplatet so effizienter arbeiten kann. Man kann kleinere Dateien auch komplett in den Speicher laden (TMemorystream), was allerdings wieder auf Kosten des Arbeitsspeichers geht. Es gibt auch noch Memory Mapped Files, bei denen die Pufferung anscheinend automatisch von Windows übernommen wird, aber wei lich mich damit noch nicht befasst habe, kann ich dazu nichts sagen.

Das sind jetzt so ein paar Sachen, die mir spontan einfallen, wenn es um Optimierungen geht.