Programm blockiert ganz Windows

[Gruber_Hans_12345]

Hi

Hab mal eine Frage, an was liegt es, dass mein Programm, wenn es etwas tut (zb per IBX Daten abruft, oder einfach ne große schleife, wo was gemacht wird)
Dass das ganze Windows hängt?

Der Taskmanager zb geht nur kurz auf, und das wars, Programme umschalten mit Alt Tab geht auch nicht mehr, aber wenn ein Texteditor offen ist, dann kann man in dem nach schreiben, wenn man den bereich noch gesehen hat vorher.

Wenn mein Programm mit der Ausführung fertig ist dann geht wieder alles ganz normal.

Wo kann ich da zum suchen anfangen?

[Perlsau]

Windows ist ereignisorientiert. Ereignisse erzeugen Messages. Während eines Schleifendurchlaufs werden keine Messages abgearbeitet, wenn du das nicht in dein Programm einbaust. Füge dazu in deiner Schleife mindestes ein Application.ProcessMessages ein und du wirst sehen, daß dann wieder alles abgearbeitet wird. Alternativ kannst du solche Schleifen auch in einen Thread auslagern, was für Anfänger gewöhnlich jedoch zu hohe Anforderungen stellt.

[Bernhard Geyer]

Ganz blockieren ist eigentlich nicht möglich. Aber im Zusammenhang mit hoher Festplattenlast + Virenscanner kann die Verarbeitung schon sehr verzögert werden.

[Perlsau]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1220012)

Ganz blockieren ist eigentlich nicht möglich. Aber im Zusammenhang mit hoher Festplattenlast + Virenscanner kann die Verarbeitung schon sehr verzögert werden.

Du hast sicher recht damit, für den gemeinen Anwender erscheint das aber schon so. Ich hab das selber schon oft erlebt, z.B. wenn ich einmalig größere Datenmengen zwischen Datenbanken kopiere (z.B. beim Umstieg auf ein anderes DBMS) und vor oder nach dem Next in der While Not Dataset.Eof-Schleife mal wieder Application.ProcessMessages vergessen habe. In solchen Fällen kannst du mit deinem Windows kaum noch arbeiten, obwohl natürlich hin & wieder die eine oder andere Message gaaanz laaangsaaam verarbeitet wird :stupid:

Da hilfts auch nicht, im Taskmanager die Priorität des Prozesses zu verringern ...

[Gruber_Hans_12345]

Zitat:

Zitat von Perlsau (Beitrag 1220003)

Windows ist ereignisorientiert. Ereignisse erzeugen Messages. Während eines Schleifendurchlaufs werden keine Messages abgearbeitet, wenn du das nicht in dein Programm einbaust. Füge dazu in deiner Schleife mindestes ein Application.ProcessMessages ein und du wirst sehen, daß dann wieder alles abgearbeitet wird. Alternativ kannst du solche Schleifen auch in einen Thread auslagern, was für Anfänger gewöhnlich jedoch zu hohe Anforderungen stellt.

Ich dachte mir das Application.ProcessMessages brauche ich in den SChleifen nur damit MEIN programm noch refresht wird und reagiert

In meinem Fall reagieren der Task Manager und das umsachalten IM WINDOWS mit zb "Alt Tab" gar nicht mehr

[Gruber_Hans_12345]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1220012)

Ganz blockieren ist eigentlich nicht möglich. Aber im Zusammenhang mit hoher Festplattenlast + Virenscanner kann die Verarbeitung schon sehr verzögert werden.

Nein, Festplattenlast gibts in dem Fall fast gar nicht, es wird zB.: einfach eine richtig große Datenmenge vom Firebird Server geholt .... in der Zeit blockiert natürlich mein Programm

ABER eben auch die anderen Programm bzw eigetnlich nur das Windows System ...

[QuickAndDirty]

Seit WindowsXP braucht ja Windows keine aktive Freigabe von Prozessorzeit durch den Entwickler.

Aber seltsamer weise gibt es doch immer wieder Dinge die Windows enfrieren lassen können. z.b.
wenn man sich auf einem Netzwerklaufwer zum erstenmal verbindet.
Oder wenn man in der Kommandozeile eine Konsolenanwendung aus einem Netzwerklaufwerk heraus startet.
Oder wenn man im Explorer auf die Netzwerkressourcen klickt und er sucht....alles friert ein.
Außer der Maus.

Ich hasse das...

[Perlsau]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1220014)

Ich dachte mir das Application.ProcessMessages brauche ich in den SChleifen nur damit MEIN programm noch refresht wird und reagiert

Es ist, wie ich es oben beschrieben habe: Dein Programm blockiert die Messages, wenn du sie nicht abarbeitest. Messages werden in Windows reihenweise an alle Tasks quasi "durchgereicht" (stimnt nicht ganz, denn eigentlich landen Messages einfach in der Message-Queue). Wenn das Ziel einer Message nicht der Task ist, für den die Message bestimmt ist, dann kriegt sie der nächste Task, um zu prüfen, ob sie für ihn ist. Auf diese Weise kann jedes Programm auch Messages, die für andere Programme bestimmt sind, abfangen und darauf reagieren.

Alles, soweit mir bekannt, ich kann mich auch irren ...

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1220014)

In meinem Fall reagieren der Task Manager und das umsachalten IM WINDOWS mit zb "Alt Tab" gar nicht mehr

Na dann bau halt mal, wie empfohlen, Application.ProcessMessages in deine Schleife ein.

[Perlsau]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1220015)

Nein, Festplattenlast gibts in dem Fall fast gar nicht, es wird zB.: einfach eine richtig große Datenmenge vom Firebird Server geholt .... in der Zeit blockiert natürlich mein Programm
ABER eben auch die anderen Programm bzw eigetnlich nur das Windows System ...

Wenn dein Firebird-Server auf demselben BS läuft wie deine Anwendung, dann entsteht selbstverständlich ausgiebiger Festplattenzugriff beim Einlesen großer Datenmengen in den Speicher. Da du aber nur selten eine riesige Datenmenge im Speicher zur Verfügung haben mußt, solltest du deine Datasets so einstellen, daß eben nicht alles geholt wird. Bei mir mit IbDac stelle ich dazu das Property FetchAll auf False. Bei großen Datenmengen entsteht z.B. auch beim Setzen von IndexFieldNames (sortieren) eine hohe Prozessorlast ...

[nahpets]

Und nicht vergessen, Windows hat eine Auslagerungsdatei und die wird benutzt, auch wenn noch Speicher frei ist. Und das gibt Festplattenzugriff in nicht zwingend unerheblichem Maße. Auch dann, wenn die Daten von einem X-beliebigen anderen Datenbankserver geholt werden.

Schau doch mal, nach Einbau von Application.ProcessMessages in der Schleife, im Taskmanager nach, ob und wie sich die Nutzung des virtuellen Speichers Deines Programmes ändert. Dann siehst Du, ob auf die Festplatte zugegriffen wird.
Und schau mal, ob sich die Anzahl der Seitenfehler verändert, dann wird Speicherinhalt aus der Auslagerungsdatei in den Arbeitsspeicher geholt. Und dahinter stecken Festplattenzugriffe. Ggfls. werden andere Programme aufgefordert Speicher freizugeben oder der Speicherinhalt anderer Programme wird von Windows in die Auslagerungsdatei verschoben, auch da stecken Festplattenzugriffe hinter.

Wenn man sehr viel Arbeitsspeicher hat, kann man mal den Versuch starten, Windows ohne Auslagerungsdatei zu konfigurieren. Gerade bei Datenbankanwendungen habe ich wiederholt die Erfahrung gemacht, dass sie dadurch deutlich beschleunigt werden können.

[Perlsau]

Zitat:

Zitat von nahpets (Beitrag 1220019)

Wenn man sehr viel Arbeitsspeicher hat, kann man mal den Versuch starten, Windows ohne Auslagerungsdatei zu konfigurieren. Gerade bei Datenbankanwendungen habe ich wiederholt die Erfahrung gemacht, dass sie dadurch deutlich beschleunigt werden können.

Eine langsame Datenbank-Anwendung kann auch in einer RamDisk ausgeführt werden (oder die Datenbank in die RamDisk kopieren), was die Verarbeitungsgeschwindigkeit deutlich erhöht. Man darf nur nicht vergessen, vor Beenden der RamDisk alles zu sichern :twisted:

[nahpets]

@Perlsau

Naja, 'ne Oracle-Datenbank auf 'ne RamDisk, ob das noch geht?
Mit viel Speicher meine ich sowas von 32 oder 64 oder mehr GB :-)

Aber das mit der RamDisk habe ich auch mal ausprobiert und feststellen müssen, dass das langsamer sein kann, als nur Arbeitsspeicher und Festplatte. Ok, das ist schon (gefühlt) ein paar Jahrzehnte her.

[Perlsau]

Zitat:

Zitat von nahpets (Beitrag 1220023)

Naja, 'ne Oracle-Datenbank auf 'ne RamDisk, ob das noch geht? Mit viel Speicher meine ich sowas von 32 oder 64 oder mehr GB :-)

Da gäb's wohl Probleme :? Allein schon das Kopieren in die Ramdisk dauert vielleicht schon länger als die gesamte DB-Sitzung ...

Zitat:

Zitat von nahpets (Beitrag 1220023)

Aber das mit der RamDisk habe ich auch mal ausprobiert und feststellen müssen, dass das langsamer sein kann, als nur Arbeitsspeicher und Festplatte. Ok, das ist schon (gefühlt) ein paar Jahrzehnte her.

Ein paar Jahrzehnte? 1993? 1983? Ich hab das vor ein zwei Jahren mit einer Firebird-Datenbank* ausprobiert, die ca. 1 GB groß ist und zahlreiche Bilder enthält. Der Aufbau des Formulars war in der RamDisk merkbar flotter als sonst. Die Trägheit der Anwendung liegt natürlich an schlechter Programmierung, da mach ich inzwischen einiges anders.

* Die verlinkte Testversion hat natürlich weniger ...

[I woars net]

Also ich fände es ganz nützlich, wenn der TE grob beschreiben würde, was sein Programm auf welchem Rechner wie tut, statt hier "herumzuorakeln" :lol:

Alles lokal, über Intranet oder übers Indernett?

[Sir Rufo]

Für eine Beurteilung wäre es schon hilfreich das Betriebssystem zu kennen.

Ab Windows 7 sollte es solche gravierenden Hänger eigentlich nicht mehr geben, da hier mehrere Prozesse gleichzeitig ihre Oberfläche updaten können.

Ein Blick in den Task-Manager kann auch nicht schaden und in der Leistungsansicht im Menü "Ansicht/Kernel-Zeiten anzeigen" einschalten.

Wenn dort jetzt alles rot ist, dann ist idR die Festplatte am jaulen ;)

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Ab Windows 7 sollte es solche gravierenden Hänger eigentlich nicht mehr geben, da hier mehrere Prozesse gleichzeitig ihre Oberfläche updaten können.

Habe ich z.B. auch das nach einem Rechnerneustart einmalig nach ein paar Minuten ein Hänger für ca. 10 Sekunden passiert. Ist ein Win7-System mit i3 und GeForce 315 Karte.

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Ein Blick in den Task-Manager kann auch nicht schaden und in der Leistungsansicht im Menü "Ansicht/Kernel-Zeiten anzeigen" einschalten.

Würde ich gerne. Aber selbst der Taskmanager ist nicht erreichbar :-(

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Wenn dort jetzt alles rot ist, dann ist idR die Festplatte am jaulen ;)

Ist bei mir während dieser Sekunden der Fall.

[Sir Rufo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1220033)

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Ab Windows 7 sollte es solche gravierenden Hänger eigentlich nicht mehr geben, da hier mehrere Prozesse gleichzeitig ihre Oberfläche updaten können.

Habe ich z.B. auch das nach einem Rechnerneustart einmalig nach ein paar Minuten ein Hänger für ca. 10 Sekunden passiert. Ist ein Win7-System mit i3 und GeForce 315 Karte.

Da würde ich mal einfach den Grafiktreiber unter Generalverdacht stellen (weil es so einfach ist).

[I woars net]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1220033)

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Ab Windows 7 sollte es solche gravierenden Hänger eigentlich nicht mehr geben, da hier mehrere Prozesse gleichzeitig ihre Oberfläche updaten können.

Habe ich z.B. auch das nach einem Rechnerneustart einmalig nach ein paar Minuten ein Hänger für ca. 10 Sekunden passiert. Ist ein Win7-System mit i3 und GeForce 315 Karte.

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Ein Blick in den Task-Manager kann auch nicht schaden und in der Leistungsansicht im Menü "Ansicht/Kernel-Zeiten anzeigen" einschalten.

Würde ich gerne. Aber selbst der Taskmanager ist nicht erreichbar :-(

Zitat:

Zitat von Sir Rufo (Beitrag 1220029)

Wenn dort jetzt alles rot ist, dann ist idR die Festplatte am jaulen ;)

Ist bei mir während dieser Sekunden der Fall.

Habs als stiller Mitleser zur Kenntnis genommen.

[Gruber_Hans_12345]

Also der Datenbankserver ist auf einem anderen Rechner

Das Problem tritt hauptsächlich auf windows 7 (das ist mein Rechner) aber auch andere die Windows 8 haben haben gesagt des alles einfriert

Und wenn es einfriert (also die Daten geladen werden (leider brauche ich alle Daten, da ein Pivot gefüllt wirt)) dann kann man den Taskmanager öffnen, er wird sozusagen einmal angezeigt und das wars, also reagiert auf keinen Mausklick oder so ...
wenn ich im Hintergrund auf Notepad++ schalte, dann kann ich zwar keine Menüs öffnen im Notepad aber noch schreiben ...

Das Problem ist das ich in der Laderoutine vom Firebird keine Porcessmessages einbauen kann.....

[mkinzler]

Zitat:

Das Problem ist das ich in der Laderoutine vom Firebird keine Porcessmessages einbauen kann.....

Warum nicht?

Dann verwende Threads

[Gruber_Hans_12345]

Zitat:

Zitat von mkinzler (Beitrag 1220047)

Zitat:

Das Problem ist das ich in der Laderoutine vom Firebird keine Porcessmessages einbauen kann.....

Warum nicht?

Dann verwende Threads

weil das ja nur ein sql.open ist was die ganze arbeit macht....

mich störts ja nicht das mein programm einfriert - aber warum der ganze rechner....

[mkinzler]

Zitat:

mich störts ja nicht das mein programm einfriert - aber warum der ganze rechner....

Weil dein Programm den Prozessor auslastet.
Vielleicht sollte man die Abfage optimieren

[Gruber_Hans_12345]

Zitat:

Zitat von mkinzler (Beitrag 1220049)

Zitat:

mich störts ja nicht das mein programm einfriert - aber warum der ganze rechner....

Weil dein Programm den Prozessor auslastet.
Vielleicht sollte man die Abfage optimieren

Ja aber das Teil hat ja noch 3 andere ...

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1220049)

Zitat:

mich störts ja nicht das mein programm einfriert - aber warum der ganze rechner....

Weil dein Programm den Prozessor auslastet.

Wage ich zu bezweifeln.
Selbst die billigesten PCs (Netbooks) haben schon zwei Kerne. Der normal-PC hat 4-8 Kerne. Ein einfaches Programm dieser Art wird den Prozessor nicht auslasten können.

[stahli]

Einen Tipp habe ich nicht aber...

Ich kenne ein ähnliches Verhalten unter Win7 gelegentlich vom InternetExplorer bzw. beim öffnen mehrerer Register. Nach einigen Sekunden läuft es dann wieder.

Außerdem reagiert das System gelegentlich nicht mehr auf MouseOver und MouseClick (laufende Programme aber schon).
Es hilft dann der Affengriff und zwei Klicks auf abbrechen. Der erste bringt die Mauserkennung zurück, der zweite schließt die Systemebene.

[EWeiss]

Hier rumzurätzeln warum das so ist bringt einfach nichts.
Fakt ist jedoch wenn du anderen Prozessen nicht die möglichkeit gibst weiterarbeiten zu können
hält das System nun mal (scheinbar)an bis dein prozess beendet ist.
Das ist einfach ein schlechter Programmierstil.

Die lösung ist doch einfach.
Blockiere nicht die Prozesse anderer Awendungen und gut ist.
Kann ich nicht.. gibt es nicht.

Das hilft immer

Delphi-Quellcode:

procedure WinProcessMessages;
// Allow Windows to process other system messages
var
  ProcMsg: TMsg;
begin
  while PeekMessage(ProcMsg, 0, 0, 0, PM_REMOVE) do
  begin
    if (ProcMsg.message = WM_QUIT) then
      Exit;
    TranslateMessage(ProcMsg);
    DispatchMessage(ProcMsg);
  end;
end;

Wer also will dir verbieten dafür zu sorgen das andere prozesse ihren Dienst verrichten können
FireBird ? :lol:

gruss

[Gruber_Hans_12345]

mir war das einfach absolut neu, das wenn ich in mienem Programm die Message nicht verarbeite das dann alle anderen Programme dadurch in mittleidenschaft gezogen werden.

Aber das Problem, ist trotzdem ich habe leider auch Komponenten von mir, die einfach sehr sehr lange zum verarbeiten brauchen (zum Beispiel PivotTabellen, die rieseige Datenmengen verarbetien) und da kann ich nicht einfach rumwerklen im sourcecode, und dort ne message loop einbauen.
Genau so schwer wird es sein das in nen Thread auszulagern, da diese Komponente natürlich auch grafisch ist ... und die GUI braucht (die ja nicht thread sicher ist)

[samso]

Nach meiner Erfahrung treten solche Effekte unter Windows7 dann auf, wenn eine Komponente den Explorer nutzt, und eine Ereignisbehandlung länger dauert. Ein Beispiel ist der DateTimePicker. Wenn man hier in den OnChange-Event folgendes einhängt

Delphi-Quellcode:

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
  Sleep(10000)
end;

dann hängt nach der Änderung des Datums der gesamte Desktop für 10s. Das liegt daran, dass der Explorer als zentrale Bedienoberfläche für 10s blockiert ist. Bei anderen Komponenten (z.B. TEdit) ist ein solches Verhalten nicht zu beobachten.

[Luckie]

Zitat:

Zitat von EWeiss (Beitrag 1220124)

Fakt ist jedoch wenn du anderen Prozessen nicht die möglichkeit gibst weiterarbeiten zu können

Das ist unmöglich. Es sei den du gibst deinen Prozess die höchste Priorität, so das alle anderen Prozesse vom Scheduler nicht mehr berücksichtigt werden.

[Gruber_Hans_12345]

Ja ist ein total komisches verhalten vom System

Und es ist total egal welche Priorität ich meinem Programm gebe - hohe oder niedrige - das hat keinen einfluss!

Wenn das programm sperrt, dann kann ich Alt-Tab drücken
es kommt das schöne fenster mit den Vorschaubildern der aktiven Programmen, aber es bleibt beim ersten Fenster stehen, also ein weiteres Alt-Tab geht nicht mehr
Die Vorschaubilder bleiben auch solange stehen bis mein programm fertig ist

Wenn ich im hintergrund bei einer anderen Anwendung was rumschreibe oder so, dann sehe ich das sogar in den kleinen Vorschaubildern automatisch refresht!

[Gruber_Hans_12345]

Zitat:

Zitat von samso (Beitrag 1220310)

Nach meiner Erfahrung treten solche Effekte unter Windows7 dann auf, wenn eine Komponente den Explorer nutzt, und eine Ereignisbehandlung länger dauert. Ein Beispiel ist der DateTimePicker. Wenn man hier in den OnChange-Event folgendes einhängt

Delphi-Quellcode:

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
  Sleep(10000)
end;

dann hängt nach der Änderung des Datums der gesamte Desktop für 10s. Das liegt daran, dass der Explorer als zentrale Bedienoberfläche für 10s blockiert ist. Bei anderen Komponenten (z.B. TEdit) ist ein solches Verhalten nicht zu beobachten.

Das muss ich morgen gleich mal probieren, ob es genau das verhalten ist, was ich bei meinem Programm auch festegestellt habe
Wie gesagt es sieht bei mir auch aus wie wenn "nur" der Desktop hängt

[EWeiss]

Zitat:

Das ist unmöglich. Es sei den du gibst deinen Prozess die höchste Priorität

Dann widersprichst du dir selbst!
Erst unmöglich und dann doch?

Na egal... sollte mich vielleicht etwas mehr zurückhalten.

gruss

[Jasocul]

Das passiert beim Open einer Query?
Dann mach davor doch davor ein DisableControls und danach ein EnableControls. Dazwischen vielleicht noch ein Application.ProcessMessages.

Ich kann mir nicht vorstellen, dass das Open den Rechner derartig ausbremst, aber die verbundenen Controls können schon einen ganze Menge verursachen.

[Gruber_Hans_12345]

Zitat:

Zitat von Jasocul (Beitrag 1220359)

Das passiert beim Open einer Query?
Dann mach davor doch davor ein DisableControls und danach ein EnableControls. Dazwischen vielleicht noch ein Application.ProcessMessages.

Ich kann mir nicht vorstellen, dass das Open den Rechner derartig ausbremst, aber die verbundenen Controls können schon einen ganze Menge verursachen.

nein, es sind gar keine Controls verbunden, das ist nur eine Query die eine PivotTabelle befüllt
aber braucht dafür natürlich sehr lange zum öffnen ...

[p80286]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1220362)

nein, es sind gar keine Controls verbunden, das ist nur eine Query die eine PivotTabelle befüllt
aber braucht dafür natürlich sehr lange zum öffnen ...

Wenn das "open" lange braucht, dann hat der DB-Server gut zu tun. Da der aber auf einer ganz anderen Maschine sitzt sollte das ****egal sein.
Wenn Du dann die Daten abholst könnte es etwas Last geben.
Das beschriebene Verhalten finde ich sehr seltsam.

Gruß
K-H

[Gruber_Hans_12345]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1220321)

Zitat:

Zitat von samso (Beitrag 1220310)

Nach meiner Erfahrung treten solche Effekte unter Windows7 dann auf, wenn eine Komponente den Explorer nutzt, und eine Ereignisbehandlung länger dauert. Ein Beispiel ist der DateTimePicker. Wenn man hier in den OnChange-Event folgendes einhängt

Delphi-Quellcode:

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
  Sleep(10000)
end;

dann hängt nach der Änderung des Datums der gesamte Desktop für 10s. Das liegt daran, dass der Explorer als zentrale Bedienoberfläche für 10s blockiert ist. Bei anderen Komponenten (z.B. TEdit) ist ein solches Verhalten nicht zu beobachten.

Das muss ich morgen gleich mal probieren, ob es genau das verhalten ist, was ich bei meinem Programm auch festegestellt habe
Wie gesagt es sieht bei mir auch aus wie wenn "nur" der Desktop hängt

Also das hätte ich gerade getestet, da hängts bei mir nicht, zumindest nicht in nem kleinen testprogramm nicht -> nur das Programm selbst natürlich, aber der Rest Desktop und co gehen noch

[Gruber_Hans_12345]

Also hab gerade ein kleines Testprogramm geschrieben, mit dem ich das ganze nachstellen wollte -> und siehe da
in dem Testprogramm bleibt der Desktop aktiv -> also keine Probleme, und nur mein kleines Testprogramm hängt

Also muss es irgendeinen nebeneffekt von meinem Hauptprogramm sein (Aber das sind leider schon doch ein paar zeilchen ... ;) )

[Morphie]

Bist du sicher, dass du nirgends SetPriorityClass verwendest?
Durchsuche mal den gesamten Code danach... Unter umständen auch den Code deiner Fremdcontrols (falls du den Code hast)

[Gruber_Hans_12345]

Zitat:

Zitat von Morphie (Beitrag 1220377)

Bist du sicher, dass du nirgends SetPriorityClass verwendest?
Durchsuche mal den gesamten Code danach... Unter umständen auch den Code deiner Fremdcontrols (falls du den Code hast)

Nix gefunden aber auch ein SetPriorityClass dürfte doch nur dann den einen Prozessor beeinflussen oder?
Ich habe ja nur 25% CPU Last auf das gesammte System gesehen in dem Fall ..

[Captnemo]

Wenn ich deinen ersten Post lese, dann steht da:

Zitat:

(zb per IBX Daten abruft, oder einfach ne große schleife, wo was gemacht wird

was ist denn mit der großen Schleife? Hast du da mal mir Application.ProcessMessages experimentiert?
Manchmal ist es bei solchen Sachen auch ganz hilfreich, wenn man sich eine Logdatei mitschreibt und quasi jeden Schritt eine Zeitaufwendigen Funktion mit einem Zeitstempel mitloggt. So kann man dann explizit die verursachende Zeile finden.

Delphi-Quellcode:

procedure log(s: string);
var
  tc, tdiff: Cardinal;
  f: Textfile;
  logfile: string;
begin
  tc:=GetTickCount;
  tdiff:=tc-stc;  
  logfile:=extractfilepath(application.exefile)+'log.txt';
  Assingfile(f, logfile);
  if fileexists(logfile) then append(f) else rewrite(f);
  writeln(f, inttostr(tdiff)+' '+s);
  closefile(f);
  application.processmessages;
end;

Das hab ich mal so aus dem Kopf hier geschreiben. Also wenn Fehler drin sind, reißt mir nicht den Kopf ab.

in der unit noch die stc: Cardinal deklarieren.
Und am begin der fraglichen Funktion stc:=gettickcount;
und dann nach bedarf ein log('jetzt wir SQL.open ausgeführt'); setzen.

Hinterher kannst du in der Logdatei recht genau sehen, wo die Zeit verbraten wurde. Möglicherweise hilft das bei der Ergründung des Problems.

Wenn's sinnvoll ist, dann kann man auch noch andere Variablen mit übergeben und loggen, damit man ggf. auch auf unlogische Daten oder so prüfen kann.