Entwickler-Ecke :: Thema anzeigen - Vista bringt mich um ... Processmessages braucht 100 ms :-(

Uwe.F. - Mi 18.07.07 07:52
Titel: Vista bringt mich um ... Processmessages braucht 100 ms :-(

Hallo liebe Vista-Leidensgenossen,

ein Application.Processmessages braucht unter XP etwa 0 - 1 Millisekunden. Ab und zu genehmigt XP sich dann mal um 80 ms (etwa jedes 10. Mal).

Vista degegen frisst jedes Mal rund 180 Millisekunden :(
Damit verliere ich mit schöner Regelmäßigkeit meine Syncronisierung innerhalb der Applikation.

Hat jemand eine Idee, was Vista da macht? Und noch besser: wie ich deas abstellen kann?
Application.Processmessages muss ich leider einbauen, weil die App andernfalls nicht bedienbar ist.

Oder gibt es da einen anderen Trick?

Beste Grüße,
Uwe

Rechner: ein alter PIV/1800 mit 512 MB. 3 Partitionen (XP, Vista und W98SE)

Gausi - Mi 18.07.07 08:11

Was Vista da macht weiß ich nicht. Folgende Vorschläge: Führe das Application.ProcessMessages nicht zu oft aus. Wenn es in einer Schleife steht, dann ruf das nur jeden 10./100./1000. Schleifendurchlauf auf, je nach dem, was in einem Durchlauf alles passiert.

Besser wäre jedoch, du lässt diese lange Berechnung in einem eigenen Thread laufen.

Uwe.F. hat folgendes geschrieben:

Damit verliere ich mit schöner Regelmäßigkeit meine Syncronisierung innerhalb der Applikation.

Den Satz verstehe ich nicht. Du nutzt APM zum Synchronisieren? Wie denn das? Und warum?

UGrohne - Mi 18.07.07 08:46

Generell empfehle ich: Vista nicht mit weniger als 2GB RAM. Mit 1GB lässt sich zwar auch noch damit arbeiten, aber so richtig schön, wirds erst mit dem Doppelten. Schau Dir dazu mal die Speicherauslastung nach dem Windows-Start an, dann wirst Du wahrscheinlich schon sehen, dass Deine 512MB eigentlich schon weg sind. Das heißt, Vista muss auf die Festplatte auslagern und genau da kommen wahrscheinlich Deine 180ms her, denn die Festplatte ist wie Du sicher weißt, das langsamste Glied in der Kette.

Darüberhinaus stört mich das Wort "Synchronisation" im Zusammenhang mit ProcessMessages. Wenn Du etwas synchron haben solltest, solltest Du Dir wenn möglich Threads einrichten, mit entsprechenden Synchronisierungsmethoden. Dann brauchst Du auch kein ProcessMessages mehr, da Deine Berechnung in einem anderen Thread läuft, wie Deine Anwendung und Du somit eine bessere Bedienbarkeit schon von Haus aus hast, solange der Prozessor durch Deine Berechnungen nicht eh schon über die Maße hinaus beansprucht wird.

Uwe.F. - Mi 18.07.07 10:51

Hallo Zusammen,

die Applikation bekommt über das MME alle 250 ms Audiodaten (über eine Call-Back-Prozedur). In dieser Call-Back-Prozedur wird dann ein Flag gesezt "neue Daten da...".
Mein Proggi verarbeitet die Daten dann (dauert nur wenige Millisekunden) und wartet dann auf neue Daten

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

Repeat
  ...
  Verarbeite Daten...
  ...
  repeat
    sleep(10);   / 10 ms lang nix tun
    application.processmessages // unter XP nahezu 0 ms, unter Vst teilw. 180 ms 
  until NewDataAvailable;
until Abbruch-Taste gedrückt

Das ist mit "Synchronisation" gemeint.

Und wenn dann im System "irgend ein Bit hustet", dauert das processmessages schnell 250 ms und ich verliere Daten (neue Daten kommen und die alten sind noch nicht bearbeitet...).
Unter XP habe ich nahezu 0 ms, und "wenn so ein Bit hustet" mal 20 bis max. 50 ms.

Wenn ich aber application.processmessages nicht einbaue, kann der Nutzer mein Programm nicht bedienen (z.B. die Abbruch-Taste drücken).

Wenn das Ding mal 20 Sekunden oder mehr läuft, sollte sich doch trotz 512 MB ein stabiler Zustand ohne ständiges Hin-und-Her-Swappen eingestellt haben, so dass keine 200 ms mehr für Processmessages verbraucht werden.

Beste Grüße,
Uwe

Gausi - Mi 18.07.07 11:02

Du solltest dringend dein Programmdesign überarbeiten ;-). Sowas

Delphi-Quelltext

1:
2:
3:
4:

repeat 
    sleep(10);   / 10 ms lang nix tun 
    application.processmessages // unter XP nahezu 0 ms, unter Vst teilw. 180 ms  
  until NewDataAvailable;

ist ja mal absolut tödlich.

Eine Möglichkeit wäre, mit Events oder Messages zu arbeiten. D.h. Wenn neue Daten da sind, setzt du nicht das Flag um , sondern schickst eine Message an dein Fenster "NeueDatenDa" und dann startest du die Verarbeitung. Wenn du damit fertig bist, brauchst du nichts tun - die nächste Message kommt dann irgendwann.

Wenn die Verarbeitung wirklich recht fix geht, dann dürfte das auch ohne einen eigenen Thread recht gut gehen.

Delete - Mi 18.07.07 11:30

Uwe.F. hat folgendes geschrieben:

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

Repeat
  ...
  Verarbeite Daten...
  ...
  repeat
    sleep(10);   / 10 ms lang nix tun
    application.processmessages // unter XP nahezu 0 ms, unter Vst teilw. 180 ms 
  until NewDataAvailable;
until Abbruch-Taste gedrückt

Das tut schon fast weh. Windows ist nun mal kein Echtzeit-Betriebssystem. Aber die Schnittstelle bietet dir doch extra eine Callback-Funktion an, die immer dann aufgerufen wird, wenn neue Daten vorliegen. Das schrteit doch gerade nach einem eigenen Ereignis oder einer eigenen Nachricht.

OlafSt - Mi 18.07.07 14:06

Wenn die Verarbeitung der Daten nur ein paar ms dauert, dann würde ich das ganze Processing in den Callback stecken.

Ansonsten bietet sich ein Workerthread an, der auf einen TEvent lauscht und selbigen Event nach der Verabeitung "deaktiviert" - während vom Callback der TEvent "aktiviert" wird. Aber das wäre hier mit Kanonen auf Spatzen.

Delete - Mi 18.07.07 19:21

Uwe.F. hat folgendes geschrieben:

Quelltext

1:
2:

    sleep(10);   // 10 ms lang nix tun
    application.processmessages // unter XP nahezu 0 ms, unter Vst teilw. 180 ms

Beste Grüße,
Uwe

Diese beiden Befehle machen doch fast das Gleiche:

sleep(10); // 10 ms lang nix tun
application.processmessages;

Wozu???

// 10 ms lang nix tun ist nicht richtig! Im Programm geschieht zwar nichts, aber das Betriebssystem oder andere Programme bekommen 10 ms "Zeit" geschenkt.

UGrohne - Mi 18.07.07 21:17

Die machen ganz und gar nicht dasselbe. Sleep bewirkt ein Pausieren des Threads, in der die Anwendung abläuft. ProcessMessages sorgt aber dafür, dass die Nachrichten-Warteschlagen des aktuellen Prozesses abgearbeitet wird. Hier arbeitet der THread also. Das hat nichts damit zu tun, ob andere PRogramme oder Windows selbst noch arbeiten. Windows ist ein "Multi-Threaded"-OS, jeder Thread bekommt eine ganz bestimmte CPU-Zeit zugewiesen, dann kommt der nächste dran usw. Das Sleep bezieht sich aber nur auf den aktuellen Prozess!

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!