eine sache die ich mich schon öfters mal gefragt habe: wie stark lasten eigentlich mehrere timer (so einige timer), ich denk da an die 200, das system aus? ich vermut mal stark, dass das von ihrem interval abhängt.
hat hier jemand schon mal erfahrungen mit gemacht?

mfg der_zaehe

Ich weis es zwar nicht, aber generell kann man auch mit einem Timer arbeiten! Man erstellt sich nur einige Variablen vom Typ Boolean und nennt sie z.B. Timer1Enabled, Timer2Enabled... und noch einige Cardinals als Intervalle. Das lässt sich alles in einen Timer packen und schont so im Endeffekt rechenleistung. Wenn ich auch nicht weis, wie solche Timer funktionieren. Vielleicht bauen sie jeder einen Thread auf? Das wäre ja ... schrecklich ^^

200 Timer... Ich tippe einfach mal auf ein schlechtes Konzept. Kein Mensch braucht für irgendwas 200 Timer - das lässt sich unter Garantie anders lösen. Timer lasten das System aus. Ob sie einen eigenen Thread beanspruchen (@JayEff) wage ich zu bezweifeln, aber sie kosten in jedem Fall enorm Rechenleistung. Also nicht darüber nachdenken - gleich einen anderen Ansatz wählen

AXMD

Mit Threads läuft das nicht (jedenfalls nicht bei TTimer). Viele Komponenten (egal ob Timer oder Buttons) kosten immer Resourcen und können zu extremer Systemlast führer (je nach System). Ein Timer macht nichts anders, als Windows anzuweisen in x Sekunden eine Nachricht WM_TIMER zu schicken, damit darauf reagiert werden kann. Wenn du also 200 Timer benutzt, so werden sich früher oder später in einer Nachrichtenliste einige WM_TIMER ansammeln, die vor den wichtigeren Messages ausgewertet werden müssen. Also ja, es lastet aus

Gruß,
maxk

STIMMT die WM_TIMER... das hätte ich wissen müssen... Man stelle sich 50000 WM_TIMER s vor, und der User hat grade WM_QUERYENDSESSION gesendet... ^^' Aber wie ich schon gesagt hab, man kann 50000 Timer in einen Einzigen stecken.

Wobei aber die meiste Last durch die VCL verursacht wird. In einer Test-Anwendung hab ich Problemlos über 200 KB\s nur im WParam einer Windows-Nachricht zwischen zwei Prozessen verschickt (4 Byte pro Nachricht). Die Sache dabei war aber, dass ich mich um die Message-Queue selber gekümmert hab.. Bei den Windows-Nachrichten seh ich daher weniger einen Engpass, eher in der VCL.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

es geht jetzt nicht direkt darum, das ich tatsächlich ein projekt habe, in dem derart viele timer vorkommen , es hat mich nur generell interessiert, ob das funktioniert.
ich hatte mal ein prog (der BAKTERIENSIMULATOR!!) das, wie der name schon verrät, bakterien in einer petrischale (jedoch der einfachheit halber einer viereckigen) simuliert hat. ich habe im endeffekt nur einen timer verwendet, jedoch hätte ich auch die möglichkeit gehabt, für jedes bakterium einen zu nehmen, das hätte dann 700*700 timer maximal bedeutet . das kam mir dann doch ein wenig überladen vor.

Na dann... die Timer haben (fast) keinen Einfluss auf die Prozessorlast. Spannend ist nur, was an den Timern dran hängt.
Timer an sich machen aber gar nix, da kannste meines Wissen nach tausende gleichzeit verwenden und nix passiert.

Hm also wie wir erfahren haben, haut jeder Timer eine Message auf den Queue und das heist dann: Wenn ich WM_Close an meine Anwendung sende, dann muss ich 700*700 Messages warten... Genau so mit den Maustasten, Tastatur... => Keine Ahnung was du mit der Prozessorlast meinst, aber das Prog selber sieht sehr eingefrohren aus.

So : ich hab nu mal ein Prog mit 7000 Timern erzeugt und gebe offen zu, es hat tatsächlich ca 5 sekunden gedauert, bis
das Prog sich nach einer WM_Close - Message geschlossen hat. Ich gebe weiterhin zu, dass 7000 Timer in der Tat die Queue ein wenig aufblähen... Ich revidiere also meine Aussage es macht NIX aus; nur einfrieren tut da nix. Warum auch ?
Ferner gebe ich aber auch zu, daß alle Timer ohne Ereignisse laufen was aber trotzdem Messages in der Queue auslöst.

Die schlauste Aussage zu dem Thema aber ist die, daß kein Mensch so viele Timer braucht und dieses ganze Thema
rein hypothetisch ist. Wenn jemand noch etwas interessantes dazu beisteuern möchte, dann fülle er die Timer mit Leben
und wir gucken mal was dann passiert; obwohl das Ergebnis wohl klar ist.
Gefragt war aber nur ob nur die Timer an sich die Anwendung einfrieren und mein Versuch sagt nein.

Zur Erläuterung meines Versuchs :

Wenn ich mehr als 7000 Timer erzeuge lösen die ersten bereits aus bevor die Fehlenden erzeugt werden können.
Hierdurch bricht die Scchleife die die Timer erzeugt ab. Etwas aufwändiger programmiert könnte man dieses Problem
natürlich umschiffen - nur wer will das ?

So das war jetzt sehr ausfühlich...
Also ich glaube wir sind uns einig, dass im Alltag der Gebrauch von Timern (da die OnTimer- Events ja gefüllt werden) sehr Programmbremsend sind, oder?

...Wenn du die eine Message auf der Queue meinst, nein, wenn du aber meinst,d ass wir niemals mit mehr als 5000 Timern arbeiten sollten, JA

@JayEff: Streich mal bitte 2-3 Nullen von den 5000 ... Dann sollte das hinkommen ...

Die Windows-Queue ist zwar schnell (nach eigenen Messungen bis 200 KB\s im Param-Teil, das heißt aber nicht, dass man das machen muss.

Bei den Timern kommt wie gesagt ein gewaltiger Aufwand im Kernel dazu, da die Timer ständig ausgewertet werden müssen, welche denn schon abgelaufen sind. Das Beschleunigt das System auch nicht grad, wenn man 80% Kernel-Auslastung hat (ab ca. 90%* steht die Maus nahezu) ...

*Hab nen bescheiden programmierten SCSI-Treiber für'n Scanner, daher weiß ich das aus eigener Erfahrung ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.