Zitat von jim_raynor:

Kann es sein, dass dein Problem nicht das Parsen ist sondern der Aufbau der Liste im Formular (also das was du im Syncronize machst)?

Das Parsen ist nicht das Problem (auch wennd as performanter ginge). Das Problem ist, mehr oder weniger, der Aufruf, damit das ganze nicht einfriert.

Zitat von jbg:

Oder rufst du MyThread.Execute immernoch direkt auf?

Ähm ja, das mache ich so. Sonst bräuchte ich ja irgendwie eine Endlosschleife, die ich per Suspend und Resume steuern müsste, was mir nicht sehr professionel klang. Aber ich lasse mich gerne korrigieren.

Zitat von Matze:

Ähm ja, das mache ich so.

Dann kannst du den Thread gleich in die Tonne schmeißen, wenn du ihn gar nicht nutzt.

Zitat:

Sonst bräuchte ich ja irgendwie eine Endlosschleife

Soll das heißen, dass du folgendes möchtest:

• Benutzer drückt taste
• Thread starten
• Wenn Thread beendet ist, kann Benutzer weitere Taste drücken

Wenn du genau das willst, dann hast du Multithreading noch nicht verstanden. (was ich jetzt nicht hoffe)

Zitat:

Suspend

Suspend sollte man schon mal gar nicht benutzen, denn das kann zu Deadlocks führen, wenn man den Thread an einer ungünsitgen Stelle anhält (die POSIX Threads von Unix/Linux bietet ein Suspend schon mal von Haus aus gar nicht an).

Zitat von jbg:

Wenn du genau das willst, dann hast du Multithreading noch nicht verstanden. (was ich jetzt nicht hoffe)

Nein, genau das möchte ich ja nicht. Der Anwender soll während dem Parsen schreiben können und das Parsen soll im Hintergrund, eben in einem extra Thread, geschehen.

Hier liest man so viel über Suspand, Resume, WaitFor aber irgendwie ist alles nichts rechtes.

Probiere es mal so (Code funktioniert natürlich nicht 1:1, ein wenig überlegen gehört auch zum Programmieren):

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyThread = class(TThread)
  private
    FText: string;
  protected
    procedure Execute; override;
  public
    constructor Create(const AText: string);
  end;

{ TMyThread }
constructor TMyThread.Create(const AText: string);
begin
  FText := AText; // initialisieren
  inherited Create(False); // und starten
  FreeOnTerminate := True;
end;

procedure TMyThread.Execute;
begin
  // FText ist hier nun verfügbar

  CalculateQuickbarArray(FText); // FText statt myMemo.Text an ParseRegExpr() übergeben
  Synchronize(ParseQuickBar); // ParseQuickBar sollte nicht mehr viel machen!
end;

...

type
  TForm1 = class(TForm)
  ...
  private
    FMyThread: TMyThread;
    procedure MyThreadTerminated(Sender: TObject);
  end;

procedure TForm1.MyThreadTerminated(Sender: TObject);
begin
  FMyThread := nil; // neuen Thread in MyMomeKeyDown() erlauben
end;

procedure TForm1.MyMemoKeyDown(...)
begin
  if not Assigned(FMyThread) then // wenn im Moment kein anderer Thread läuft ...
  begin
    FMyThread := TMyThread.Create(myMemo.Text); // ... einen neuen Thread starten
    FMyThread.OnTerminate := MyThreadTerminate;
  end;
end;

Hallo Andreas,

nun geht es deutlich besser als vorhin und ruckelt kaum noch. Das bisschen ligt nun sicher an der Funktion, die ich mit Synchronize aufrufe, das optimiere ich noch etwas. Vielen Dank.

Zitat von jbg:

[...] ein wenig überlegen gehört auch zum Programmieren

Das nehme ich persönlich. Auch wenn man es nicht merkt, ich habe Stunden, wirklich Stunden gesucht und gelesen und bin nie auf deine Methode gestoßen.

Zitat von Matze:

Zitat von jbg:

[...] ein wenig überlegen gehört auch zum Programmieren

Das nehme ich persönlich. Auch wenn man es nicht merkt, ich habe Stunden, wirklich Stunden gesucht und gelesen und bin nie auf deine Methode gestoßen.

Wieso hast Du nicht die Online-Hilfe gelesen? Die paar Beispiele im Demo-Verzeichnis von Delphi reichen doch auch aus. Im Übrigen dürfte sich seine Anmerkung auf den nicht getesteten Code beziehen, den man nicht 1:1 übernehmen sollte, weil eben "ein wenig Überlegen" auch "zum Programmieren" gehört. Ehrlich gesagt frage ich mich, wo du gelesen hast. Es gibt übrigens noch andere Quellen außer DP.

So, nun zum Fachlichen:
Du solltest einen Workerthread erzeugen. Der wartet, bis etwas zu tun ist, verrichtet seine Arbeit und wartet dann wieder.

markieren

Delphi-Quellcode:

Procedure TWorkerThread.Execute;
Begin
  While Not Terminated Do
    If WaitForSingleObject (fMySemaphore,nil,nil, 500) = WAIT_OBJECT_0 do
      DoSomething
End;

Im 'DoSomething' wird dann dein Text verwurstet o.ä.

Zitat von Matze:

Hier liest man so viel über Suspand, Resume, WaitFor aber irgendwie ist alles nichts rechtes.

Das 'WaitForSingleObject' ist Rechtens. Es ist die von Windows empfohlene Methode, weil sie, laut Online-Hilfe (Du erinnerst Dich? ), sehr effektiv ist. Beim Warten wird also so gut wie keine CPU-Zeit verbraten. Das ist also, im Gegensatz zu deinem Gefühl, sehr professionell.

Das 'fMySemaphore' ist eine Semaphore, die man zur Kommunikation mit Threads verwenden kann: Eine Semaphore ist sowas wie ein threadsicher Zähler, und WaitForSingleObject wartet drauf, das der Zähler <> 0 ist. Dann wird der Zähler um 1 verringert und die Funktion verlassen (Steht alles in der OH). Wenn man will, das der Workerthread arbeiten soll, muss man nur die Semaphore hochzählen. Das geht dann mit 'ReleaseSemaphore', die die Semaphore hochzählt. So kann man -auch über Prozessgrenzen hinweg- einen Thread anstossen.

Um dem Thread also mitzuteilen, das er arbeiten soll, rufst Du einfach:
ReleaseSemaphore (fMySemaphore,1,Nil) auf. Eine Semaphore wird z.B. so erzeugt (schau in der Win32-Hilfe nach der Bedeutung der Parameter):
fMySemaphore := CreateSemaphore(NIL, 0, 1, NIL); Da es sich um ein Handle handelt , weisst Du dann auch, wie man es wieder freigibt.

Wesentlich resourcenschonender, sozusagen die Leichtgewichtsvariante, ist eine 'Critical Section', die, man ahnt es kaum, in der OH sehr ausführlich beschrieben wird. Mit Suspend und Resume kann man einen Thread auch steuern, aber *das* ist dann nicht sehr professionell.

Hallo alzaimar,

Ich habe gegoogelt, was das zeug hält aber du hast Recht, in die OH habe ich nicht geschaut.

Danke für deine Erläuterungen, mal testen, was da nun performanter ist.