Stringfunktionen

[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.