Stringfunktionen

[himitsu]

s <> '' und s = '' prüft theoretisch auf die globale Konstante eines Leerstrings ''.
Da ein Leerstring aber einem nil entspricht, ergibt das somit eine Prüfung auf nil, bzw. 0.

Das Length ist eine Funktion und die will erstmal aufgerufen werden, also Sprung (JMP) + Rücksprung (RET), dazu noch eine IF-Abfrage und bis zu zwei ausgelesene Werte (der interne Pointer und die Längenangabe). Erst danach kommt dann deine =0 -Prüfung dran.

Try selber ist schon OK und vorallem mit Try-Finally sollte man seinen Speicher besser mal sauber halten (Resourcenschutzblöcke).
Auch das Try-Except hat etwas Gutes an sich, aber man sollte es auch ordentlich einsetzen, aber insbesondere nicht zur Ablaufsteuerung.
Eine Exception Ausnahme sollte eine Ausnahme bleiben und nicht grob fahrlässig im Übermaß missbraucht werden.

[Namenloser]

Zitat von himitsu:

Eine Exception Ausnahme sollte eine Ausnahme bleiben und nicht grob fahrlässig im Übermaß missbraucht werden.

Indy, I’m looking at you. SCNR

[relocate]

Zitat von himitsu:

s <> '' und s = '' prüft theoretisch auf die globale Konstante eines Leerstrings ''.
Da ein Leerstring aber einem nil entspricht, ergibt das somit eine Prüfung auf nil, bzw. 0.

Würde das gehen, sähe das besser aus im Quellcode. Was letztendlich aber egal ist. Es ist klar, dass der Aufruf einer zusätzlichen Funktion length() Zeit kostet. Es ging ja auch nur darum mögliche Varianten zu testen. Und so ist es eben, wenn man ggf. nicht weiß, welcher Weg optimal ist, kann Zeit verlieren. Wenn man kann, nutzt man Assembler, wenn man weiß, was man tut, kann man wohl kaum schneller werden, auch wenn Delphi schon versucht zu optimieren, wenn der Programmierer einen verqueren Weg geht, kann Delphi auch nicht mehr viel ausrichten.

Vielleicht kannst Du das erhellen. Was ich bei dem Try-Finally manchmal nicht verstehe. Beim erzeugen von Objekten soll es ja genutzt werden und im Finally steht dann die Freigabe des Objekts. Doch es soll ja mit dem Objekt gearbeitet werden und später irgendwann mal freigegeben werden, was nutzt da zu Beginn des Objektlebens ein Finally?

Mit dem Nichteinsetzen zur Ablaufsteuerung gehe ich voll konform.

[himitsu]

Wobei Assembler nicht die eierlegende Wollmilchsau ist, wofür man sie oftmals hält.

Ich hatte persönlich auch schon den Fall, daß ich mit Assembler absolut nichts optimieren konnte.
Es war nahezu genauso schnell, wie ein ordentlicher Pascal-Code und die Codeoptimierung des Compilers.
Abgesehn davon, daß man dem Assembler-Code nicht mehr ansehn konnte, was er eigentlich macht. (ohne tausende Kommentare)

Selbst wenn es ein bissl schneller sein währe, sollte man oftmals wirklich mehr an einen einfach und wartbaren Code denken.
Und jetzt vorallem auch noch in Bezug auf Multiplattform, denn der Pascalcode kann leichter an andere Systeme angepaßt werden, falls er es sowieso nicht schon ist.

Oftmals werden Objekte und andere Resourcen nur für eine gewisse Dauer benutzt.
z.B. der Zugriff auf eine Datei. Da sollte das Dateiobjekt und vorallem das interne Handle am Ende unbedingt freigegeben werden.
Genauso ein Speicherblock (GetMem), welcher benutzt und sicher freigegeben werden sollte, selbst wenn mal etwas nicht so läuft, wie es soll.
Wenn das öfters passiert, dann können einem ganz schnell die Resourcen ausgehn, bzw. die Datei ist beim nächsten Man nicht mehr zugänglich, da sie ja immernoch gesperrt ist.

[relocate]

Ach, na sicher. Inzwischen sind die Compiler so ausgefeilt, dass eine Optimierung in Assembler oftmals kaum noch Sinn macht. Und auch die Portabilität spielt eine große Rolle, wobei das für Delphi bislang eher nebensächlich war. Es wird auch inzwischen nicht einfacher, da sogar der Prozessor versucht den Programmlauf zu optimieren und dabei ggf. anders agiert, als der Entwickler das vorgesehen hat, je nach Prozessortyp.

Das erhellt in der Tat etwas und macht wirklich Sinn. War das unter TP noch einfach als man quasi den ganzen Rechner für sich hatte. Vielen Dank.

[himitsu]

Nja, in dem Fall war halt der Pascal-Code schon sehr gut.
Wobei ich auch erst dachte da noch was rauszuholen.
Nur 3 Tage später übermannte mich dann die Ernüchterung, als es ans Testen des Assemblercodes ging.

3 Tage Arbeit, für nichtmal 100 Millisekunden Zeitersparnis, bei einer Gesamtlaufzeit von knapp 30 Sekunden ... das war's absolut nicht Wert.


Es gibt auch Intelligenzbestien, welche mit Multithreading (das ist auch oftmals überbewertet) Dateioperationen optimieren wollen,
mit dem Ergebnis, daß die Singlethreadanwendung schneller war, da sich die Threads gegenseitig ausbremsten.
Bei HDDs ... SSDs haben ja nicht solche Laufzeitprobleme, wenn der Schreib-/Lesekopf ständig umpositioniert werden muß.
Gute SSDs unterstützen manchmal sogar einen paralellen Zugriff, womit Multithread dann doch Vorteile bringen könnte, aber wieviele SSDs gibt's denn ... im Durchschnitt also mehr Nachteil,
es sei denn man baut beide Varianten ein, was auch nichts bringt, da sich SSDs aktuell noch nicht sicher erkennen lassen.

[relocate]

Das kann man dann unter der Rubrik Erfahrung ablegen.

Das kann ich mir vorstellen, das liegt wirklich in keinem Verhältnis. Wenn der Assemblercode sehr komplex ist, ist es halt schwierig abzuschätzen wie weit die Optimierung klappen würde. Unter DOS war es ja Volkssport jedes Quentchen Zeit aus dem System zu holen, da es ja insgesamt alles sehr langsam war. Aber irgendwann war halt Schluss.

Hm, ja, da kann man das System sehr schnell ausbremsen, so viel zum Thema Verwendungszweck. Wenn man da nicht weiß, wie die Hardware funktioniert dann hilft auch nichts mehr. Ist die Frage ob es soviel Geschwindigkeitszuwachs gibt, wenn der nächste Zugriff ebenfalls schnell geht. Dann kann man sich den Multithreadaufwand sicher sparen.

So langsam wird der Thread zum Optimierungsthema.

[himitsu]

Zitat von relocate:

Unter DOS war es ja Volkssport jedes Quentchen Zeit aus dem System zu holen

Das gibt es heite auch noch. Ob nun Linux, Windows oder Sonstewas, das ist hierbei egal.

Das fängt mit NonVCL an.
(siehe die Beiträge im Forum und unzähligen Beispiele auf Luckies Webseite www.michael-puff.de )
Dort verzichtet man auf große vorgefertigte Bibliotheken (vorallem die VCL) und macht nahezu alles selber.

Oder schau dir Mal die Demoszene an, die machen vielleicht kranke Sachen.
Man versucht möglichst viel in möglichst wenig reinzubekommen.
z.B. kkrieger ( www.youtube.com/watch?v=oKCFq5GsrV0 )


www.theproduct.de
www.farb-rausch.de
www.pouet.net/prod.php?which=25889
http://en.wikipedia.org/wiki/64k_intro
http://en.wikipedia.org/wiki/Farbrausch (gibt's sogar in deutsch)
http://www.delphipraxis.net/132115-d...mme-~-1kb.html
...

[relocate]

Klar gibt es das heute noch, aber früher war es ja fast schon zwingend.
(DOS Speichergrenze, PCs im MHz Bereich statt GHz-Wahnsinn, manchmal habe ich das Gefühl die PCs von heute sind da nicht schneller, ich weiß, heute passiert auch viel mehr auf den Maschinen unter Windows, aber viele Programme sind rausgeschleudert, nach dem Motto Hauptsache geht, wie ist egal.)

Natürlich war da auch die Demoszene Vorreiter.

NonVCL entwickle ich zum Teil auch. Bin aus der Admin-Schiene und um meine Arbeit zu erleichtern schreibe ich mir das ein oder andere Tool.
Damit es schneller geht oft erst VCL aber die Größe der EXE Dateien schreckt mich oft ab und dann fange ich an zu optimieren, wenn das Tool öfter zum Einsatz kommt.

KKrieger kenne ich, das Ding hat mein Laptop auf dem Gewissen.
(Nein, nicht wirklich, aber beim Abspielen ist er fast den Hitzetod gestorben).

Farbrausch kenne ich daher auch.

Das kannte ich noch nicht. Dass es da noch mehr Reserven gibt mit dem Austausch der System Unit, cool.

Nochmals, vielen Dank.