TStringlist mit 60000 Einträgen zu langsam

[hoika]

Hallo,

Zitat:

also ein bisschen hat es was gebracht, aber nicht viel..

Du stocherst also etwas rum und es bringt nicht viel.

Warum findest du nicht erst mal raus, was so bremst ?

Entweder durch einen Profiler oder "auskommentieren".

Ich würde z.B. erst mal das ganze "Wort suchen" durch
"kompletten String nehmen" ersetzen und testen.


#Update#

Delphi-Quellcode:

function gibmirLemma(s:string; sep:char) :string;
var
  t: Tstringlist;   
begin
  //hier muss jetzt das zweite Wort rausgefiltert werden
  t:= tstringlist.create;
  try
    extractstrings([char(sep)], [' '], pchar(s), t);
    result:= t.Strings[2];
  finally
    t.free;
  end;
end;

Wieso muss hier eine StringList erzeugt werden ?
OK, das ominöse ;) extractstrings will das haben.
Wie sieht denn der Code extractstrings aus ?

[char(sep)] ein offenes Array mit nur einem Zeichen, wozu dann ein array ?

Wie es aussiehtst, missbrauchst du die StringList hier,
du gibst sie ja auch wieder frei.


Heiko

[Uwe Raabe]

Zitat:

Zitat von hoika

[char(sep)] ein offenes Array mit nur einem Zeichen, wozu dann ein array ?

...oder ein set of Char?

[hoika]

Hallo,

ja oder so.
Ist hier aber überhaupt nicht notwendig, nur langsamer.


Heiko

[Reinhard Kern]

Hallo,

ein Text mit TAB-separierten Daten ist doch ein klassischer Fall für einfach von Anfang bis Ende durchparsen - von der Logik her ist es völlig unnötig mehr als eine aktuelle Zeile überhaupt im Speicher zu haben. Wieso muss man hier in der DP immer für einfachste Aufgaben möglichst komplizierte VCL-Elemente benutzen? Auf Ruhm und Ehre unter fanatischen Code-Ideologen kann ich gern verzichten, dafür habe ich dann einfache und schnelle Programme.

Einen durchgehenden Text seriell zu verarbeiten ist keineswegs steinzeitlich und hinterwäldlerisch, das machen auch professionelle gekaufte Programme so.

Meinetwegen kann jetzt die Prügelei losgehen, ich werde trotzdem so weiter programmieren, ich muss ja hier nichts davon veröffentlichen.

Gruss Reinhard

[friedemann2009]

@Reinhart, was meinst du damit?

Gruß, friedemann

[Jaynder]

Also auf die schnelle ist mir aufgefallen, das friedemann

1. lokal ständig neue Objekte anlegt und wieder freigibt, was bei diesen Größenordungen nicht zu vernachlässigen ist
2. die string-Parameter als "call by value" übergibt, was bedeuetet, das jedesmal eine Kopie angelegt und wieder freigegeben wird; "const" würde da sehr helfen

Ansonsten stimme ich Reinhard zu, ein ordentlicher Parser ist mit Sicherheit die beste Lösung.

[hoika]

Hallo,

Zitat:

von der Logik her ist es völlig unnötig mehr als eine aktuelle Zeile überhaupt im Speicher zu haben.

Einspruch Euer Ehren ;)

Das Zusammenbauen der Ziel-"Datei" im Speicher
würde ich viell. auch so machen.
Dann geht das mit dem "Ganz oder gar nicht Speichern" einfacher
(OK, man könnte die "halbe" Datei bei einem Fehler wieder löschen)

Das "Ganz oder gar nicht Speichern" war ja jetzt keine Anforderung,
könnte aber sein ... ;)

Ich denke, das Grundproblem sind die "Hole Wort X" Aufrufe.
Ob ich jetzt die Ausgangsdatei zeilenweise bearbeite
oder alles in eine StringListe packe, ändert daran nichts (vom Speucher abgesehen).

Ich würde deshalb ganz gern mal den ExtractStrings-Code sehen.
Gab es hier nicht mal eine Diskussion über Explode ?


Bei schlechter Laufzeit sollte eh ein Profiler genommen werden,
sonst wird an der falschen Stelle optimiert.


Zu const
Ist mir noch gar nicht aufgefallen ;)

An den TE
also aus

Delphi-Quellcode:

function gibmirLemma(s:string; sep:char) :string;

wird

Delphi-Quellcode:

function gibmirLemma(const s:string; sep:char) :string;

Heiko

[Jaynder]

Zitat:

Zitat von hoika

Hallo,
Wird nicht seit D2 eh nur eine Zeiger übergeben ?
Heiko

Stimmt schon (weiß zwar nicht mehr seit wann), aber trotzdem passiert Speicherverwaltungstechnisch eine ganze Menge mehr, wenn der Parameter lokal verändert werden darf.

Aus

Delphi-Quellcode:

function test1(const s:string; sep:char) :string;
begin
  Result := S;
end;

wird kurz und knapp

Code:

Main.pas.106: begin
push ebx
push esi
mov esi,ecx
mov ebx,eax

Main.pas.107: Result := S;
mov eax,esi
mov edx,ebx
call @UStrAsg

Main.pas.108: end;
pop esi
pop ebx
ret

dagegen bläht sich

Delphi-Quellcode:

function test2(s:string; sep:char) :string;
begin
  Result := S;
end;

ganz fürchterlich zu

Code:

Main.pas.101: begin
push ebp
mov ebp,esp
push ecx
push ebx
mov ebx,ecx
mov [ebp-$04],eax
mov eax,[ebp-$04]
call @UStrAddRef
xor eax,eax
push ebp
push $004a3bcc
push dword ptr fs:[eax]
mov fs:[eax],esp

Main.pas.102: Result := S;
mov eax,ebx
mov edx,[ebp-$04]
call @UStrAsg

Main.pas.103: end;
xor eax,eax
pop edx
pop ecx
pop ecx
mov fs:[eax],edx
push $004a3bd3
lea eax,[ebp-$04]
call @UStrClr
ret 
jmp @HandleFinally
jmp $004a3bc3
pop ebx
pop ecx
pop ebp
ret

aus. Man muss das ja nicht alles verstehen, aber bei zeitkritischen Sachen summiert sich das ganz erheblich und man sollte es im Hinterkopf behalten. Ich schreibe inszwischen bei Strings ganz automatische immer const davor.

[himitsu]

Delphi-Quellcode:

Ich schreibe inszwischen bei Strings ganz automatische immer const davor.

Jupp, am Besten man gewöhnt sich sowas allgemein an, so ist man vor mehrere unangenehmen überraschungen besser geschützt.
(also einfach bei allem, welches nicht direkt mit Integern, Chars, Booleans und Objekten zu tuen hat)

[hoika]

Hallo,

wie ihr seht, habe ich die entsprechende Passage schon gelöscht ;)


Heiko