Stringfunktionen

[relocate]

Zitat von DeddyH:

Zunächst muss eine Routine zuverlässig funktionieren, danach kann man dann sehen, wie man die Geschwindigkeit ggf. erhöhen könnte. Dreht man diese Reihenfolge um, kommt selten etwas Brauchbares dabei heraus.

Klar, Zuverlässigkeit steht an erster Stelle, leider leidet die Effizienz immer mehr, die neue Hardware bügelt das ja schon aus.

Ich habe mal ein Char aus einem String herausgelöst. Was bei einem Leerstring eine Exception wirft, also muss das getestet werden. Ich habe das mit folgenden Varianten gemacht:

1)

Delphi-Quellcode:

if wort = '' then chrtest := #0
else chrtest := wort[1];

2)

Delphi-Quellcode:

if wort <> '' then chrtest := wort[1]
else chrtest := #0;

3)

Delphi-Quellcode:

if length(wort)=0 then chrtest := #0
else chrtest := wort[1];

4)

Delphi-Quellcode:

if length(wort)>0 then chrtest := wort[1]
else chrtest := #0;

5)

Delphi-Quellcode:

try 
  chrTest := wort[1];
except
  chrTest := #0;
end;

Auf meinem PC war die Variante 2 die schnellste, wenn auch nur unwesentlich schneller als 1.
Variante 4 hat ungefähr doppelt solange gedauert, wiederum unwesentlich schneller als 3.
Der Try Block etwas langsamer noch als 3/4 (außer die Exception wurde geworfen, das hat gedauert).

Wenn der Fall eintrat dass der String leer war erhöhte sich die Abarbeitungszeit.

Auf einem anderen, älteren PC war das anders. Die Variante 1 und 2 wurden deutlich schneller bei einem Leerstring. Und die Varianten 3 und 4 etwas schneller. Also ist auch noch relevant wie man testet und welcher der Ziel PC ist. Der Try Block war auch da langsamer bei einer Exception.

[himitsu]

Zitat:

Delphi-Quellcode:

try
  chrTest := wort[1];
except
  chrTest := #0;
end;

Sowas sollte man auch niemals machen.
Denn fang jetzt mal an dein Programm zu debuggen, wenn da genügend solcher Code drin vorkommt,
dann kannst'e dich auch gleich erschießen, denn sowas macht absolut keinen Spaß mehr.

Im Fall von Zahlen ist das sehr gut beobachtbar:

Delphi-Quellcode:

try
  i := StrToInt(s);
except
  i := 0;
end;

// oder

i := StrToIntDef(s, 0);

Delphi-Quellcode:

try
  i := StrToInt(s);
  {mach was mit i}
except
end;

// oder

if TryStrToInt(s, i) then
  {mach was mit i}

Vorallem leere except-end-Blöcke sind grauenhaft.


Bezüglich der Unterschiede zwischen = und <>.
Dort hängt es sehr von den Eingangsdaten ab.
Da ist mir persönlich fast immer alles egal und ich verwende die Variante, welche ich besser lesen kann. Außerdem versuche ich durchgängig nur eine Variante zu verwenden, weil man den gesamten Code dadurch auch besser verstechen kann. (man verliest sich weniger)

[relocate]

Zitat von himitsu:

Zitat:

Delphi-Quellcode:

try
  chrTest := wort[1];
except
  chrTest := #0;
end;

Sowas sollte man auch niemals machen.
Denn fang jetzt mal an dein Programm zu debuggen, wenn da genügend solcher Code drin vorkommt,
dann kannst'e dich auch gleich erschießen, denn sowas macht absolut keinen Spaß mehr.

Ich bin auch kein Freund von den Try-Blöcken. Ich hatte ja geschrieben, ich kam von Turbo Pascal 6, da gab es solche feinen Sachen noch nicht. Na ja, nicht direkt. Da musste z.B. die I/O Kontrolle ausgeschaltet werden und über IOResult das Ergebnis abgefragt. Ist quasi ein Try Except Block. Aber in diesem Fall funktioniert es ja. Ich kam darauf, weil ja eine Exception stattfand, also konnte es damit abgefangen werden. Allerdings finde ich, wer das so nutzt ist zu Faul sauber zu programmieren. In manchen Fällen wohl aber nicht zu vermeiden.

Zitat von himitsu:

Im Fall von Zahlen ist das sehr gut beobachtbar:

Delphi-Quellcode:

try
  i := StrToInt(s);
except
  i := 0;
end;

// oder

i := StrToIntDef(s, 0);

Delphi-Quellcode:

try
  i := StrToInt(s);
  {mach was mit i}
except
end;

// oder

if TryStrToInt(s, i) then
  {mach was mit i}

Vorallem leere except-end-Blöcke sind grauenhaft.

Das mit den Zahlen schaue ich mir mal an, habe mir das aber mit dem Code den ich gepostet habe auch gemacht. Ich fand jetzt die Abfrage nach ='' so billig mit Length hat mehr Stil, ich benutze aber trotzdem ='' und das mit den leeren Except Blöcken ist logisch.

Zitat von himitsu:

Bezüglich der Unterschiede zwischen = und <>.
Dort hängt es sehr von den Eingangsdaten ab.
Da ist mir persönlich fast immer alles egal und ich verwende die Variante, welche ich besser lesen kann. Außerdem versuche ich durchgängig nur eine Variante zu verwenden, weil man den gesamten Code dadurch auch besser verstechen kann. (man verliest sich weniger)

In diesem Fall gab es ja kaum Zeitunterschiede, aber auch das ist klar. Man prüft besser auf den Sonderfall und den Standardfall lässt man so durch gehen (ich habe es irgendwo besser formuliert stehen).

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