![]() |
AW: Quelle hoher Prozessorauslastung ermitteln
Eure Tipps sind ja nicht schlecht, aber sie beantworten nicht die Frage des OP. Mich wundert es, dass hier noch niemand das Stichwort „Profiler“ in den Raum geworfen hat. Für Delphi gibt es da den kostenlosen
![]() (Man muss aber unbedingt vom Compiler eine ausführliche MAP-Datei erzeugen lassen (geht in der Projektoptionen), sonst kann man nicht viel daraus ablesen) |
AW: Quelle hoher Prozessorauslastung ermitteln
Zitat:
Zitat:
|
AW: Quelle hoher Prozessorauslastung ermitteln
Zitat:
|
AW: Quelle hoher Prozessorauslastung ermitteln
Stress. Stress Stress. Daher komme ich erst jetzt dazu, zu antworten. Hier ging's ja in der Zwischenzeit schon gut zur Sache. :)
Aus Zeitmangel, nehmt's mir nicht übel, in Kurzform: 1. Ja, es ist mein Programm. Das geht aus dem Taskmanager hervor. 2. Listen können es eigentlich auch nicht sein. Alle aufgenommenen Daten werden in ClientDatasets abgespeichert. 3. Die Profiling- und Log-Tools werde ich mir mal näher ansehen. |
AW: Quelle hoher Prozessorauslastung ermitteln
Okay, vielen Dank schonmal an alle bis hierhin. :thumb:
Ich bin leider noch nicht dazu gekommen, mir die Profiler und Logger anzuschauen. Trotzdem bin ich immerhin einen Schritt weiter. Denn ich habe testweise einfach mal meine Routine zum Schreiben der Daten in die Datasets (die mit einer TLineSeries im DBChart verbunden sind) auskommentiert. Und siehe da: Keine Probleme mehr.
Delphi-Quellcode:
Mach ich hier irgendwas Grundlegendes falsch, das die lange Rechenzeit verursacht?
if not FCDSTemperatur.Active then
begin FCDSTemperatur.Open; end; FCDSTemperatur.Edit; FCDSTemperatur.Append; FCDSTemperatur.FieldByName('Zeitstempel').AsDateTime:=now; FCDSTemperatur.FieldByName('Wert').AsFloat:=FTemperatur; FCDSTemperatur.Post; FCDSTemperatur.SaveToFile; edit: Der Ordnung wegen eher eine Sache für einen neuen Thread? |
AW: Quelle hoher Prozessorauslastung ermitteln
Ich sehe da zwei potentielle Kandidaten.
1. Das
Delphi-Quellcode:
Wird dieser Dataset immer wieder geschlossen und neu geöffnet, wird immer wieder der komplette Datenbestand aus dem Speicher geworfen und neu eingelesen. Mit steigender Datenmenge dauert dieses neu einlesen immer länger.
FCDSTemperatur.Open
2.
Delphi-Quellcode:
Natürlich dauert mit wachsendem Datenumfang das Wegschreiben des ganzen Datenbestands immer länger. Allerdings denke ich ist ClientDataSet clever genug, nur das allerneueste in die Datei zu speichern.
FCDSTemperatur.SaveToFile
Ich tippe also auf ersteres und ich würde diese beiden Stellen einfach mal genauer untersuchen. |
AW: Quelle hoher Prozessorauslastung ermitteln
Es macht keinen Sinn ein TClientDataSet an dieser Stelle zu benutzen. Bei dem SaveToFile wird jedesmal die komplette Datenmenge in die XML Datei geschrieben. Dass das nicht gerade schnell ist, sollte klar sein.
Das einzig sinnvolle ist eine Embedded Datenbank, ob nun SQLite, Firebird Embedded oder MS SQL Embedded spielt dabei keine große Rolle. Da du ja (hoffentlich) nur von diesem einen Programm auf die Daten zugreifst, reicht eine Embedded Datenbank ohne echten Datenbankserver vollkommen aus. |
AW: Quelle hoher Prozessorauslastung ermitteln
Ja, das ist logisch. Bin allerdings, ebenso wie Olaf, davon ausgegangen, dass nur die neuen Datensätze weggeschrieben werden. Schade.
Gibt's zu den Embedded DBs irgendwo einsteigerfreundliche Tutorials? Bin leider noch nirgends fündig geworden. :? Vielen Dank bis hierher! :thumb: |
AW: Quelle hoher Prozessorauslastung ermitteln
Zitat:
![]() Und ein Tutorial: ![]() Selbst kenne ich beides nicht (ich habe immer dbExpress genutzt und nun FireDAC, aber das hast du nicht), habe aber viel Gutes darüber gelesen. |
AW: Quelle hoher Prozessorauslastung ermitteln
Moah, ich brauch' Urlaub, kann nicht mal mehr anständig googeln...
Recht herzlichen Dank!8-) Ich fuchs' mich da mal rein. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz