[Bug?] Delphi ist zu langsam?

[alzaimar]

Zitat von Sir Rufo:

Jepp ein Thread ist genau das Richtige dafür.

Äh... Nö. Was soll der Anwender im Vordergrund anderes tun, wenn im Hintergrund der Thread abläuft?

Zitat von Sir Rufo:

Deine User/Kunden werden dankbar sein ...

Nun ja, eher herablassend lächeln. Der Spieltrieb lässt ab einem gewissen Alter stark nach.

Mach lieber Folgendes (das ist einfacher und für Deinen Anwendungsfall genauso gut):
Wenn Du z.B. eine Liste von Dateien hast, mit denen etwas geschieht, dann pack eine Progressbar auf die Form und dann das hier:

Delphi-Quellcode:

Procedure TForm1.ProcessMyFiles (Files : TStrings);
Var
  i : Integer;

Begin
  CancelButtonPressed := False; // Privates Boolean-Feld deiner Form
// Der Benutzer kann auf einen 'Abbruch' Knopf (CancelButton) drücken, siehe unten
  ProgressBar.Max := Files.Count+1;
  ProgressBar.Min := 0;
  For i:=0 to Files.Count Do Begin
    ProgressBar.Position := i+1;
    ProcessOneFile(Files[i]);  // Eine Datei verarbeiten
    Application.ProcessMessages; // Mausbewegungen und Buttonclicks abarbeiten lassen
    If CancelButtonPressed Then Break; // Abburch gedrückt? Na dann: Abbruch!
  End;
End;

Procedure TForm1.CancelButtonClick (Sender : TObject);
Begin
  CancelButtonPressed := True;
End;

So sähe das schon etwas hübscher aus. Wenn nun jedoch das 'ProcessOneFile' länger als ungefähr 5 Sekunden braucht, sagt die Ergonomie-Lehre, das man noch zusätzliche Informationen anzeigen sollte. Der Anwender soll nicht denken, das die Büchse hängt.
Also kannst Du z.B. in einer zweiten Progressbar den Fortschritt innerhalb der Datei anzeigen.

Wichtig ist, das man ab und an 'Application.ProcessMessages' aufruft. Was die Routine macht? Nun, alle Interaktionen, also Tastendrücke, Mausklicks und -bewegungen etc. werden an die Anwendung in eine Botschaftsliste (Messagequeue) gepackt. Die Anwendung arbeitet nun im Leerlauf immer diese Liste ab, sodaß eben sofort auf Button-Clicks etc. reagiert wird. Das siehst Du nicht, das macht das Application-Objekt alleine.

Wenn Du aber nun rumrechnest, kommt die Application nicht mehr dazu, also musst Du ihr ab und an die Arbeit abnehmen.

Wenn Du natürlich zu oft Application.ProcessMessages aufrufst, dann verlangsamst Du deine Arbeit. Daher kannst Du z.B. bei einem Zähler nur jedes 100ste Mal die Messagequeue abarbeiten lassen. Das passt schon.

Und der Abbruch-Button gibt dem Anwender die totale Kontrolle.

Wozu ein Thread, wenn der Anwender doch nichts anderes machen kann?

[igel457]

Zitat von alzaimar:

Wozu ein Thread, wenn der Anwender doch nichts anderes machen kann?

Es gibt nur einen Grund: Besseres Programmdesign. Wenn du mit Threads programmierst, kannst du die Berechnungen zum Beispiel auf mehrere Prozessorkerne aufteilen und somit auf Multicoreprozessoren schneller zu einem Ergebnis kommen.

Delphi-Quellcode:

procedure MachWas;
begin
  Thread := TMeinThread.Create;
  Thread.Resume;
  while not Thread.Terminated do
  begin
    Application.ProcessMessages;
    Sleep(10);
  end;
  Thread.Free;
end;

[Sir Rufo]

Also eine lange Berechnung interaktiv durchzuführen und mit Application.ProcessMessages die Anwendung dazu zu bringen ab und an die Anzeige zu refreshen halte ich nicht wirklich für einen guten Programmierstil.

Selbst das Minimieren und dann Wiederherstellen einer solchen Anwendung ist auf Gedeih und Verderb davon abhängig, ob dann auch vielleicht ein Application.ProcessMessages kommt.

Eine Anwendung die sich nicht mehr richtig anfühlt (minimieren - wiederherstellen - Fensterinhalt ist grau) wird oft auch einfach nur beendet. Es zeugt von schlechter Programmierung oder auch von Arroganz, wenn man den Anwender auf die Stufe eines Dummchens heruntersetzt - der soll halt gefälligst warten, ich melde mich schon, wenn was passiert, solange ist halt Schicht im Schacht.

Mit der Jedi-VCL-Komponente TJvThread sollte es eigentlich jedem möglich eine längere Berechnung in einem Thread ablaufen zu lassen, so dass es keinen Grund gibt, dieses nicht zu tun.

Aber das ist nur meine Sicht der Dinge ... ITW habe ich schon viele Negativ-Beispiele gesehen ...

cu

Oliver

[The Riddler]

Ja, ich lasse ja bereits eine ProgressBar anzeigen wie weit der Prozess fortgeschritten ist. Da teilweise ~240 Strings in einer Datei ersetzt werden, kann es aber ~15s für eine Datei dauernd bis dann der Fortschrittsbalken einen Schritt nach vorn geht.

Fremdkomponenten wie JEDI möchte ich ehrlich gesagt nicht verwenden...

[mkinzler]

Zitat:

Fremdkomponenten wie JEDI möchte ich ehrlich gesagt nicht verwenden...

Und warum?

[jbg]

Zitat von mkinzler:

Es gibt Rechenzeit ab.

Ganz im Gegenteil. Application.ProcessMessages zieht 100% CPU Last (bei einer CPU) an sich. Nur wir die Zeit für die Botschaftsverarbeitung genutzt. Ein "while not Terminated do Application.ProcessMessage;" bremst alle anderen Anwendungen aus, lässt deine Anwendung aber ratzfatz reagieren.

[Sir Rufo]

Zitat von The Riddler:

Fremdkomponenten wie JEDI möchte ich ehrlich gesagt nicht verwenden...

Die brauchst Du auch nur dann verwenden, wenn Du es nicht schaffst eine ThreadKlasse selber zu erstellen.

Das ist dann also "Threads 4 Dummies"

cu

Oliver

[divBy0]

Bis jetzt bin ich mit Threads ganz gut gefahren, auch wenn's nur mal um eine Funktion oder ging, die Zeit gebraucht hat.

Anschauen würde ich mir das schon, lohnt sich.

[Sir Rufo]

Also für alle die mal einen Thread benutzen wollen (sollen, müssen oder wie auch immer) und sich mit Händen und Füßen gegen irgendwelche Komponenten-Sammlungen welcher Art auch immer wehren, hier ein Thread-Gerüst mit angehängtem Beispiel-Projekt.

Ich war auch bemüht mittels Compiler-Schalter diverse Features in das Thread-Gerüst zu packen:

- Progress
- Status
- Events
- Datenübergabe an Thread
- CriticalSections
- Datenbank-Zugriffe

cu

Oliver

[turboPASCAL]

Zitat:

Also für alle die mal einen Thread benutzen wollen (sollen, müssen oder wie auch immer) und sich mit Händen und Füßen gegen irgendwelche Komponenten-Sammlungen welcher Art auch immer wehren

Autsch. Na das sollte man ohne eine externe Kompo. schon können müssen als Programierer. Wenn nicht Lernen soll da schon helfen.

// Edit:

@Sir Rufo, schickes Demo. Für einen Anfänger aber ggf. zu viel Zeugs in einem Programm.
Einzele Programme ürden für mer Übersichtlichkeit sorgen.