Anzahl eines Zeichens im String ermitteln

[KodeZwerg]

Man kann ja auch die RandomString() seperat aufrufen um damit eine feste Datei erzeugen.
Ich wollte den Traffic sparen und fand hier in DP diese nützliche Unit um Strings beliebiger Länge zu generieren in dem moment praktikabler aber der Replikation und Schwankungen zur Folge hast Du Recht, so ist es nur eine objektive Momentaufnahme.
Bei Tokyo ist ja TStopWatch enthalten, die Timing-Funktion kann man damit auch ersetzen/erweitern, ob damit andere/bessere Ergebnisse rauskommen?

[Uwe Raabe]

Zitat von KodeZwerg:

Bei Tokyo ist ja TStopWatch enthalten, die Timing-Funktion kann man damit auch ersetzen/erweitern, ob damit andere/bessere Ergebnisse rauskommen?

Im Wesentlichen macht TStopWatch ja auch nichts anderes. Es geht ja auch nicht um die absoluten Werte, sondern um die Vergleichbarkeit.

[EgonHugeist]

Zitat von Uwe Raabe:

Zitat von EgonHugeist:

Schaut gut aus! No a bizzl kürzer:

Braucht allerdings dann ca. 30% länger, weil das INC immer ausgeführt wird, auch wenn es gar nicht nötig ist. OK, wenn der String fast nur aus dem gesuchten Zeichen besteht, dann wäre das eine Option. Die Standardmethode aus dem StringHelper S.CountChar(C) ist da auch nicht viel schlechter (ca. 50% länger als mein letzter Ansatz und ca. 20% länger als dein Vorschlag).

Offenbar sind die Ansätze mit PChar und Inc(P) potentiell schneller als indizierte Zugriffe in For-Schleifen. Ob der erreichbare Geschwindigkeitsgewinn aber die schlechtere Lesbarkeit und Wartbarkeit (siehe die ganzen Probleme mit Assembler) rechtfertigt, ist wohl eher zweifelhaft.

Ich habe den Benchmark etwas modifiziert und rufe die einzelnen Probanden 10000x auf um lokale Schwankungen auszugleichen - natürlich außerhalb der IDE und im Release-Mode. Messungen im Nanosekundenbereich sind einfach nicht verlässlich genug. Da der String per Zufall generiert wird, kann man verschiedene Läufe auch nicht direkt miteinander vergleichen, nur die Rangfolge innerhalb eines Laufs. Der Zeichensatz ist ja auch etwas eingeschränkt gewählt.

Interessant! Danke!

String[i] ist immer langsam. Die Schleife ist da nicht unbedingt schuld, sondern die permanente Indexierung der Speicheraddresse und die damit verbundenen RangeChecks. Durch deinen CodeStyle ak. Pointer-Math gibt es eben diese Checks erst gar nicht nicht.

Delphi-Quellcode:

function CharCount(const S: string; C: Char): Cardinal;
var
  P, PEnd: PChar;
begin
  Result := 0;
  P := Pointer(S);
  if P = nil then Exit;
  {$IFNDEF FPC}
  PEnd := P + PLongInt(NativeUInt(P) - SizeOf(LongInt))^;
  {$ELSE}
  PEnd := P + PSizeInt(NativeUInt(P) - SizeOf(SizeInt))^;
  {$ENDIF}
  while P < PEnd do begin
    if P^ = C then
      Inc(Result);
    Inc(P);
  end;
end;

@Himitsu,
was soll da nicht stimmen? Das TStrRec ist sowol unter Delphi64/32 bit gleich definiert. Also wo ist der Haken, wenn du es schon ansprichst?

[himitsu]

Zitat von EgonHugeist:

Na dann klär mich mal auf! Hättest du FPC anstatt von nur "64 Bit" geschrien dann hättest du meiner bescheidenen Meinung nach recht.

Stell dir mal vor demnächst fragt jemand bei Emba an, warum Strings unter 64 Bit nicht mehr als 4 GB groß sein dürfen?
Dann ändert Emba die Struktur und es knallt.

Wenn möglich also immer vordefinierte Casts/Funktion nutzen und nicht gefährlich selber auf interne Strukturen zugreifen.

Ich sehe hier auch keinen Vorteil, weswegen nicht Length verwendet werden kann. Die Funktion hat dann sogar 70% weniger Code.
Und auch für die anderen Informationen gibt es schon seit 9 Jahren fertige Funktionen.

Delphi-Quellcode:

{ string info utilities }
function StringElementSize(const S: UnicodeString): Word; overload; inline;
function StringElementSize(const S: RawByteString): Word; overload; inline;
function StringCodePage(const S: UnicodeString): Word; overload; inline;
function StringCodePage(const S: RawByteString): Word; overload; inline;
function StringRefCount(const S: UnicodeString): Integer; overload; inline;
function StringRefCount(const S: RawByteString): Integer; overload; inline;
{$IFNDEF MSWINDOWS}
function StringElementSize(const S: WideString): Word; overload; inline;
function StringCodePage(const S: WideString): Word; overload; inline;
function StringRefCount(const S: WideString): Integer; overload; inline;
{$ENDIF}

Gut, bissl blöd ist, dass

Delphi-Quellcode:

type
  PStrRec = ^StrRec;
  StrRec = packed record
    codePage: Word;
    elemSize: Word;
    refCnt: Longint;
    length: Longint;
  end;

  PDynArrayRec = ^TDynArrayRec;
  TDynArrayRec = packed record
    RefCnt: LongInt;
    Length: LongInt;
  end;

in der System-Unit nicht öffentlich deklariert sind, sonst könnte man sie direkt zum Casten nehmen.

[EgonHugeist]

Assoooo! Und ich dachte schon ...

Der code ist mir klar. Auch die möglicherweise begleitenden Probleme die sich durch den Anruf bei Emba ergeben könnten.
Wenn man so mit dem Speicher spielt, sollte das auch klar sein.

Da greift man auch anders an:

Delphi-Quellcode:

type 
  //zentral deklariert
  PStrLenInt ^StrLenInt;
  StrLenInt = {$IFDEF FPC}SizeInt{$ELSE}LongInt{$ENDIF};
// sollte Delphi den speicher bereich über 2/4GB wie FPC-64 jemals erweitern, würde da ein weiteres Property-Based define den richtigen Type declarieren.
// somit schaut der code so aus:

function CharCount(const S: string; C: Char): Cardinal;
var
  P, PEnd: PChar;
begin
  Result := 0;
  P := Pointer(S);
  if P = nil then Exit;
  PEnd := P + PStrLenInt(NativeUInt(P) - SizeOf(StrLenInt))^;
  while P < PEnd do begin
    if P^ = C then
      Inc(Result);
    Inc(P);
  end;
end;

Das gewöhnt man sich an, wenn gleicher code von D2...XE10.2 laufen soll, jedoch inline code erst seit D2005 möglich ist und jeder call 50cycles verschwended, wie mir Uwe so schön gezeigt hat.

Bedenken hin oder her, wo jedoch ist das CPU64 Problem? Oder gibt es doch keins?

Edit
PS.: 4GB sind yuch nur für den UnicodeString verfügbar, da ElementSize = 2 ist, theoretische 8GB für einen UCS4String (wenn es den gibt unter Delphi?) und nur 2GB für all SingleByte-Long-Strings.

Edit2: Selbst wenn StrRec/PStrRec definiert wären wie soll denn dann der Cast ausschauen? Du hast nur einen Speichblock mit n-Bytes. Eine cast über PStrRec müßte auch rückwärts (SizeOf(StrRec))gerechnet werden.

[Neutral General]

Zitat von gammatester:

Zitat von Neutral General:

ACHTUNG: Da scheint auch noch irgendwo ein kleiner Denkfehler drin zu sein

Da scheint auch noch ein grundsätzlicher Fehler drin zu sein, da Du nirgends das Directionflag mit cld auf 0 setzt. Ich würde mich zumindest nicht darauf verlassen.

Ja gut das könnte (sollte) man wahrscheinlich noch machen. (Habs in meinem vorherigen Post hinzugefügt)
Aber das war nicht das Problem.
Dann hätte ich mich wahrscheinlich nicht verzählt sondern direkt ne Zugriffsverletzung erhalten.

[Uwe Raabe]

Zitat von Neutral General:

Dann hätte ich mich wahrscheinlich nicht verzählt sondern direkt ne Zugriffsverletzung erhalten.

Aber genau das ist hier passiert als ich die Funktion ausführen wollte.

[Neutral General]

Zitat von Uwe Raabe:

Zitat von Neutral General:

Dann hätte ich mich wahrscheinlich nicht verzählt sondern direkt ne Zugriffsverletzung erhalten.

Aber genau das ist hier passiert als ich die Funktion ausführen wollte.

Okay. Ich meine gammatester hatte natürlich Recht dass man mit cld auf Nummer sicher gehen sollte.
Klappt es denn mit cld als erste Anweisung bei dir?

[Uwe Raabe]

Zitat von freimatz:

sollte erst mal prüfen warum man die Suche überhaupt braucht. Die zu vermeiden ist meist der wesentlich schnellere Weg.

Hier z.B. ein Helper für TTextReader zum korrekten Einlesen einer CSV-Datei, bei der innerhalb der gequoteten Felder Zeilenumbrüche vorkommen.

Delphi-Quellcode:

function TTextReaderHelper.ReadQuotedLine(QuoteChar: Char): string;
var
  line: string;
begin
  Result := ReadLine;
  if Odd(Result.CountChar(QuoteChar)) then begin
    { Eine ungerade Anzahl von Quotes bedeutet, daß der gequotete String mindestens einen Zeilenumbruch enthält.
      Wir hängen also die nachfolgenden Zeilen mit LineBreak an, bis eine weitere Zeile mit ungerader Anzahl
      Quotes kommt.
    }
    repeat
      Result := Result + sLineBreak;
      line := ReadLine;
      Result := Result + line;
    until Odd(line.CountChar(QuoteChar));
  end;
end;

[Uwe Raabe]

Zitat von Neutral General:

Okay. Ich meine gammatester hatte natürlich Recht dass man mit cld auf Nummer sicher gehen sollte.
Klappt es denn mit cld als erste Anweisung bei dir?

Interessanterweise läuft die Funktion im Debug-Mode durch, aber im Release-Mode gibt es sofort eine Zugriffsverletzung. Dieser Effekt zusammen mit den Plattform-Einschränkungen und Maintenance-Problemen erzeugen zumindest bei mir eine Abwehrhaltung gegenüber jedweder ASM-Lösung. Ein eventuell signifikanter Geschwindigkeitsvorteil bliebe noch zu belegen.

Übrigens: Bei den Funktionen, die auch #0 Zeichen im String zulassen und somit auch danach suchen lassen, muss man beachten, daß der String immer mit einem #0 Zeichen abgeschlossen wird (bei Length + 1), aber dieses nicht mitgezählt werden darf.