Lange Rechnung, ohne dass das Programm "blockiert"

[Nicolai1234]

Im Hinblick auf die Monte-Carlo-Rechnung habe ich mir wieder eine Frage gestellt, die mir schon lange auf dem Herzen liegt!
Wenn ich eine lange Schleife habe, für die mein Rechner ein paar Minuten braucht, ist es bei mir immer so, dass das Programm in dieser Zeit nicht ansprechbar ist und im Taskmanager auch "Keine Rückmeldung" steht, obwohl das Programm nicht abgestürzt ist!
Wie kann man das ändern, sodass ich während dieser Schleife das Programm auch minimieren und maximieren kann als Beispiel?
Vielen Dank
Nicolai

[Dax]

Ganz einfach: Die Schleife in einen Thread auslagern ;)

[Union]

Zitat:

Zitat von Nicolai1605

Im Hinblick auf die Monte-Carlo-Rechnung habe ich mir wieder eine Frage gestellt, die mir schon lange auf dem Herzen liegt!
Wenn ich eine lange Schleife habe, für die mein Rechner ein paar Minuten braucht, ist es bei mir immer so, dass das Programm in dieser Zeit nicht ansprechbar ist und im Taskmanager auch "Keine Rückmeldung" steht, obwohl das Programm nicht abgestürzt ist!
Wie kann man das ändern, sodass ich während dieser Schleife das Programm auch minimieren und maximieren kann als Beispiel?
Vielen Dank
Nicolai

Entweder mit Application.ProcessMessages (aber nicht zu oft!!) oder Du legst das gesamte Berechnungsprogramm als Thread an.

[jim_raynor]

Entweder man baut Application.ProcessMessages ein oder nutzt Threads.

[edit] :wall: Warum musste ich noch mal in der OH nachschauen wie es richtig geschrieben wird, nur damit ich es dann doch falsch schreibe :wall:

[tommie-lie]

Zitat:

Zitat von jim_raynor

[edit] :wall: Warum musste ich noch mal in der OH nachschauen wie es richtig geschrieben wird, nur damit ich es dann doch falsch schreibe :wall:

Damit du der letzte von dreien bist, der den gleichen Vorschlag postet :mrgreen:

[BenjaminH]

Zitat:

Zitat von Union

mit Application.ProcessMessages (aber nicht zu oft!!)

Tut mir leid wenn ich so dumm frag aber:
Warum?
Für das System ist das doch nur gut, oder?

Benjamin

[Dax]

Nur bedingt, weil Application.ProcessMessages (zu oft aufgerufen) mehr CPU-Leistung verbraucht als die eigentliche Rechung.

[tommie-lie]

Zitat:

Zitat von BenjaminH

Zitat:

Zitat von Union

mit Application.ProcessMessages (aber nicht zu oft!!)

Tut mir leid wenn ich so dumm frag aber:
Warum?
Für das System ist das doch nur gut, oder?

ProcessMessages erzeugt einen gewissen Overhead, und wird es zu oft aufgerufen (beispielsweise in jedem Schleifendurchlauf, statt in jedem zehnten), dann wird die Rechnung messbar verlangsamt, ohne daß wirklich sinnvolle Messages bearbeitet werden. Ein ungezieltes ProcessMessages auf gut Glück hat immer einen gewissen Polling-Charakter.
Prinzipiell ist ein Thread für sowas besser geeignet, was die Performance angeht.

[roderich]

Auch wenn dies immer wieder als Lösung dieser Ploblematik vorgeschlagen wird:
ein schlichtes Aufrufen von Application.ProcessMessages z.B. in einer Schleife ist nicht risikolos.
Leicht nachvollziehbar durch Drücken von Alt+F4 während einer solchen Berechnung -> oft Absturz.

Bei Ausführung von Application.ProcessMessages werden die bis dahin "angesammelten" Messages abgearbeitet. Wenn z.B. der Menuepunkt, über den die Berechnung gestartet wurde, nicht sofort gesperrt wurde, wird der Code beim nächsten Klick darauf während der Berechnung quasi ein 2. Mal gestartet. Jeder Zugriff auf globale Variablen oder Instanzen (z.B. dein Hauptformular) kann dann in die Hose gehen.

Daher setze ich Application.ProcessMessages sparsam ein und wenn doch, sperre ich gerne mein ganzes Formular oder zumindest einige Controls (außer z.B. einem Abort-Knopf).

Roderich

[negaH]

@roderich, absolut korrekter Einwand und Lösung.
Noch ein Tipp von mir: Es ist immer schwierig abzuschätzen wie oft man nun Application.ProcessMessages aufrufen sollte. Meistens macht man das zu wenig oder eben zu oft. Die beste Abschätzung die man treffen kannist das man alle 100 ms diesen Aufruf durchführen sollte. Man kann dies mit GetTickCount erreichen:

Delphi-Quellcode:

var
  NextTick: Cardinal = 0;

procedure Poll;
var
  Tick: Count;
begin
  Tick := GetTickCount;
  if Tick >= NextTick then
  begin
    Application.ProcessMessages;
    NextTick := Tick + 100;
  end;
end;

Die procedure Poll kannst du nun ohne Bedenken in die innerste Schleife einbauen. Sie ruft Application.ProcessMessages nun nur noch alle 100 Millisekunden auf. Der restliche Overhead mit dem Aufruf von GetTickCount dauert nur noch ca. 22 Taktzyklen.

Der richtige Weg wäre ein eigener Thread aber es gibt auch gute Gründe für ein Polling wie oben:
1.) wenn die Anwendung sowieso auf die aktuelle Berechnung warten soll
2.) Polling lässt die Anwendung smooth reagieren, Threads sind konkurrent zum Mainthread und sind entweder mit tpIdle zu langsam oder mit tpNormal zu schnelle eingestellt. Egal wie man es dreht, mit Threads erscheint die Anwendung in der Bedienung immer "ruckelig".
3.) mit Threads entsteht ein nicht zu unterschätzender Aufwand beim Threadübergreifenden Zugriff auf gemeinsamme Daten. D.h. sollte die Berechnung abgebrochen werden können, oder ein Fortschritt der Berechnung angezeigt weden sollen, so benötigt man mit Threads einen erhöhten Aufwand an Locking und Synchonisation. Meistens führt dieser Aufwand dazu das man mehr Reechenzeit verschwendet als nötig. RTL CriticalSections und Messages mit SendMessage() verbrauchen viel mehr Rechenpower, als das simple Polling.

Also, wenn man nur EINE schnelle Berechnung machen möchte auf die der Anwender sowieso warten muß, dann lohnt sich die asynchrone Polling Methode. Wichtig dabei ist wie Radig es schon sagte das die Anwendung komplett gesperrt werden muß dabei.

Gruß Hagen