CPU Auslastung für ein Programm begrenzen

[Andidreas]

Zitat von Der_Unwissende:

Hi,
@Andidreas Sorry aber als etwas Aussenstehender finde ich deine Kritik, dass du doch nach weiteren Lösungen fragen kannst etwas nun ja. Natürlich kannst du immer nach weiteren Lösungen fragen, bis dir eine gefällt aber ich denke dass wäre doch irgendwie etwas ignorant. Ich denke das was Luckie sagte war nicht böse gemeint (hast du hoffentlich auch nicht so aufgefasst), aber letztlich sagt er ja nur, dass du da zwei Möglichkeiten hast.

naja ich hab mich nicht unbedingt angegriffen gefühlt, aber ich fand denn beitrag etwas komisch...
was die ignoranz betrifft, sicher frag ich nicht so lange nach bis mir eine lösung passt, aber von denn 2 antworten dich ich bis dahin bekommen hatte, war für mich keine realisierbar bzw. konnte ich mir nicht vorstellen wie mir das helfen sollte... deshalb meine frage nach weiteren lösungen...


danke noch für deine erklärung zum thema threads, ich werd mir mal bei gelegenheit (sobald ich etwas luft hab das mal auszuprobieren) ein beispiel suchen und werd mal probieren das ganze inen thread zu packen...

Edit:
noch was zur laufzeit...
naja ok 2,5 MB sind nicht wirklich viel...
aber immerhin sind es im excel am ende ca. 63.000 Sätze

[Flocke]

Schreib mal, bevor du mit der eigentlichen Schleife anfängst, ein
oleExcelApp.ScreenUpdating := False; hinzu. Das kann manchmal Wunder wirken...

[Michael Habbe]

Wenn Andreas nun nicht die 63.000 Datensätze erwähnt hätte, ich bin rein rechnerisch auf 72.817 gekommen. Und das ist schon eine ganze Menge, wenn man eine Textdatei zeilenweise einliest. Wobei ich (ein wenig) bezweifle, dass die Methode SL.LoadFromFile wie xaromz schrieb schneller ist.
Wird hier jede einzele Zelle über OLE an Excel übergeben? Ich habe damit noch nicht gearbeitet Würde mich dann nicht wundern, wenn der Performanceverlust daher rührt.

Das Application.ProcessMessages und ProgressBar.Position muss auch nicht jeden Durchlauf ausgeführt werden. Hier reicht es, wenn man der Counter ausgewertet wird und dann z.B.

Delphi-Quellcode:

  if RowCounter mod 100 = 0 then
  begin
    Application.ProcessMessages;
    ProgBar2.Position := RowCounter;
  end;

ausführt.

Zum Thema Threads: würde ich hier auf keinen Fall verwenden. Der Aufwand für die Entwicklung ist ungleich höher, da es so aussieht, als wenn das Programm "nur" die Excel-Tabelle erstellt. Und da wären Threads wohl die Kanonen auf Spatzen. Wenn ein ganzes Verzeichnis mit Dateien konvertiert werden soll, könnte sich das schon rentieren (Stichwort DualCore)

mfg
Michael

[Andidreas]

ja ich übergeb jede zeile per ole an excel...
ich weiß nicht ob es da ne möglichkeit mit blöcken zu arbeiten
müßt ich mal nachschauen ob das evtl. auch geht, würde dann vermutlich schneller gehen...

[SirThornberry]

Was die Lösung mit dem Thread bringen soll ist mir bisher noch unklar. Ob die Arbeit im Hauptthread des Programmes erledigt wird ist doch irrelevant wenn es um die dauer geht. Der Hauptthread wird genau so lange für die Aufgabe brauchen wie ein Extra Thread der mit gleicher Priorität läuft. Anstelle einen neuen Thread mit niederiger Priorität zu erstellen würde ich einfach die Priorität des Hauptthreads heruntersetzen. Durch einen zusätzlichen Thread würde nur zusätzliche Rechenzeit benötigt (weil dann der Hauptthred + der neue Thread Rechenzeit benötigt)

[Der_Unwissende]

Zitat von SirThornberry:

Was die Lösung mit dem Thread bringen soll ist mir bisher noch unklar

Es geht bei der Lösung mit dem Thread nicht um die Rechenzeit an sich, sondern die Verteilung eben dieser Rechenzeit. Egal mit welcher Priorität der Hauptthread läuft, sobald er in einer Schleife hängt bleibt keine Zeit für mehr als diese Schleife. Das heißt, minimieren, maximieren und verschieben des Fensters klappt einfach mal nicht. Benutzt man einen Thread mit geringerer Priorität (es dürfte fast normale reichen), garantiert einfach nur, dass noch Zeit für den Hauptthread bleibt, unabhängig von dem arbeitenden Prozess (der dann in einer Schleife alle Datensätze durchgeht). Natürlich ist das hier eher ein Fork als ein Nebenläufiger Prozess, gibt jedenfalls keine konkurriende Zugriffe.

[Andidreas]

Zitat von Der_Unwissende:

...Das heißt, minimieren, maximieren und verschieben des Fensters klappt einfach mal nicht...

aber dieses problem würde ich ja wenn ich klaus01 richtig verstanden hab auch mit application.processmessages in denn griff kriegen??!!! oder hab ich da was falsch verstanden??

[SirThornberry]

das hast du richtig verstanden.

[Der_Unwissende]

Hi,
das hast du zwar schon richtig verstanden, aber man sollte da doch ein wenig richtig stellen. Es wird hier so getan als ob ein Thread totalen Overhead darstellt und dich jahrelange Einarbeitung ohne sinn kostet. Also gerade weil du ein so einfaches Problem hast, ist es eigentlich kein Problem das in einen Thread auszulagern. Du musst nur eine Klasse von TThread ableiten und die Execute Methode überschreiben. Das schätze ich mal so mit ca. 5 min Aufwand ab. Sicherlich tippt sich ein Application.ProcessMessages schneller. Bleibt also die Frage nach dem Nutzen.
Also einerseits hast du noch nicht mit Threads gearbeitet und die kommen in nächster Zeit eher nicht aus dem Trend (siehe HyperThreading, MultiCore CPUs usw.). Jedenfalls ist in deinem Fall die eigentliche Schwierigkeit (die Verwaltung konkurrierender Zugriffe) gar nicht vorhanden. Damit kannst du alles was gemacht wird direkt in der Execute-Methode des Threads machen (ohne Rücksicht auf irgendwas).
Application.ProcessMessages verarbeitet alle anstehenden unbehandelten Nachrichten und kehrt dann zurück. Das heißt für dich, sobald diese Funktion aufgerufen wird, wird hier Rechenzeit verbraucht. Wurde dein Form zum Beispiel bewegt, so würde die neue Position jetzt gezeichnet werden. Wurde es nicht bewegt ist trotzdem Rechenzeit weg (auch hier gibt es einen Overhead!).
Bewegst du dein Form, merkt es dein Programm aber erst wenn Application.ProcessMessages aufgerufen wird. Solange du das nicht tust ist dein Form wieder eingefroren. Stellt sich die Frage wann aufrufen? Zu oft führt zu unnötigem Overhead, zu selten führt zu einfrieren. Und dann kommt noch das Problem, dass es auf unterschiedlich schnellen Rechnern unterschiedlich viel Overhead bedeutet.
Mit einem Thread (der in deinem Problem wirklich einfach zu realisieren ist) musst du dich nicht darum kümmern. Der verwaltet die Rechenzeit selbst. Und alle Zeit die zum zeichnen gebraucht wird, wird mit Vorrang (höhere Priorität) zu gewiesen.
Natürlich klappt es mit beiden Wegen (aber siehe auch andere Threads oder Luckies Vorschlag, die Lösung mit Threads ist die eher zu empfehlende). Ich persönlich finde es ist ein wenig der Vergleich zwischen imperativer Programmierung und OOP in Delphi, du kannst beides machen. Objekte bedeuten im ersten Moment eine Menge overhead (Konstruktoren, Destruktoren,...) aber alles in allem... (natürlich Geschmackssache).

[Andidreas]

@der_unwissende
so langsam hast du mir denn thread so schmackhaft gemacht das ich denn unbedingt haben will

aber zu meinem verständniss wieder eine frage...

application.processmessages hilft mir dabei, das während meine schleife läuft, die das excel erzeugt trotzdem die forum bewegt werden kann etc...
aber es hilft mir nicht dabei denn hauptspeicher zu begrenzen denn mein programm verwenden darf?!

aber wenn ich mir die beiträge hier zum thema threads durchlese, dann hilft mir der thread lediglich dabei das evtl. die rechenzeit bzw. die laufzeit meines programmes verkürzt wird (evtl.)...

aber effektiv kann ich durch einen thread meinem programm immer noch nicht sagen, das es z.b. nur max. 20% des cpu's verwenden darf...
und das ist eigentlich das was ich suche und gern verwende möchte falls es so was geben sollte