[Codebeispiel] Wie man es nicht macht...

[enertegus]

Hi,
ich habe hier nun schon zum 2.-ten Mal einen Code gesehen, der wenig sinnvoll ist:
[highlight=epc]
if stime(0) then pdisplay(...., MyVar, ...) endif
if stime(0) then pdisplay(...., "MyGA-1/0/7", ...) endif
...
[/highlight]
Die Idee dabei ist wohl, dass die Visu regelmäßig aktualisiert werden soll. Das ist kontraproduktiv, weil

1. die Visu sowieso Echtzeit ist. Wenn ich dann wieder nur alle 1 Minute aktualisiere, ist das ja nicht notwendig.
2. Nun werden quasi alle Webelemente exakt zur gleichen Zeit aktualsiert, was sicher Systemlast genierert.
3. Durch die Verwendung im Makro eine Vielzahl von stime-Aufrufen zusammenkommt (kann da schnell auf ein paar hundert anwachsten). Jeder Systemtimer benötigt etwas Rechenzeit, weil ja in jedem Zyklus nachgeschaut werden muss, ob der ungültig wird. An sich sind da ein paar hundert kein Problem, aber diese Programmierung hat hier zum zweiten mal zu über 1000...2000 aktive Timer geführt, was eigentlich sinnlos ist.

Das richtige Vorgehen ist mit change() zu arbeiten.
[highlight=epc]
if change(MyVar) then pdisplay(...., MyVar, ...) endif
if change("MyGA-1/0/7") then pdisplay(...., "MyGA-1/0/7", ...) endif
...
[/highlight]
Selbst wenn sich die GA mehrmals in der Minute ändert, macht das dem EibPC gar nix.
Irgendwo muss das wohl in einem User-Makro eingebaut gewesen sein, was dann einfach so übernommen wurde.

[amazing]

ich habe es mittlerweile geändert, CPU Last von 45% auf 26% gesunken, wenn es was damit zu tun hatte.

[enertegus]

ich habe es mittlerweile geändert, CPU Last von 45% auf 26% gesunken, wenn es was damit zu tun hatte.

Sicher, genau das ist der Beweis für "Jeder Systemtimer benötigt etwas Rechenzeit".

[saft6luck]

Sicher, genau das ist der Beweis für "Jeder Systemtimer benötigt etwas Rechenzeit".

Was soll denn da der Beweis sein?
Die erhöhte CPU-Last beweist nur, das sie leider nichts mit der Wirklichkeit zu tun hat.

Ich kann ja verstehen, dass man versuchen sollte, die Ereignisse nicht gehäuft auftreten zu lassen.
Dann sollte man aber auch genau das sagen und nicht mit fragwürdigen Rechenleistungs-Behauptungen argumentieren.

Genau diese ist bei stime() genauso problematisch, wie bei jedem anderen Kommando, insbesondere welche, die auf fixe Zeitpunkte triggern (besonders wenn es "gerne verwendete" Zeitpunkte sind), z.B. cycle in jeder Form.

Also, die Häufung ist das Problem.

Dass jedes Kommando Rechenzeit benötigt sollte klar sein!

Und das ist auch nicht das eigentliche Problem, sondern die mangelnde Robustheit des eibPCs Lastspitzen gegenüber.

Beispiel siehe angefügte Grafiken (grad erst aufgenommen). Hier wird das optimierte WP-Makro verwendet, welches eigentlich alle 10 Minuten aufgerufen wird. Im dargestellten Zeitraum aber leider nur alle 20 Minuten. Es wurden 2 Aufrufe "vergessen". Ein paar Minuten später sieht es wieder besser aus.

[enertegus]

Was soll denn da der Beweis sein?

Sorry deinem Chart kann ich nicht entnehmen., dass der EibPC an Alzheimer leidet und was "vergisst"... Vielleicht hat die Wp nicht geantwortet oder die Antwort war kürzer ausgefallen etc.

Die erhöhte CPU-Last beweist nur, das sie leider nichts mit der Wirklichkeit zu tun hat.

Manchmal frage ich mich, ob es hier bei dir hin und wieder um reine Provokation geht ....
Ein Timer muss jeden Zyklus nachschauen, ob er aktiv werden muss. Das generiert Systemlast, insbesondere wenn es in die Region von über 1000 aktive Timer geht. Ob du das nun besser weißt, oder auch nicht.

[saft6luck]

Sorry deinem Chart kann ich nicht entnehmen., dass der EibPC an Alzheimer leidet und was "vergisst"... Vielleicht hat die Wp nicht geantwortet oder die Antwort war kürzer ausgefallen etc.

Tja, tut er aber. Ich logge die Kommunikation mit, daher kann ich belegen, dass weder um 23:43, noch um 0:13 eine Anfrage geschickt wurde. Ansonsten gäbe es ja noch die 5 Retries.

Manchmal frage ich mich, ob es hier bei dir hin und wieder um reine Provokation geht ....
Ein Timer muss jeden Zyklus nachschauen, ob er aktiv werden muss. Das generiert Systemlast, insbesondere wenn es in die Region von über 1000 aktive Timer geht.

Es sind diese Aussagen, deren inhaltliche Tiefe mich wirklich zweifeln lässt!

1. "Ein Timer muss jeden Zyklus nachschauen, ob er aktiv werden muss."
Ein Timer prüft nichts. Es wird höchstens abgefragt. Evtl. muss er upgedatet werden. Mancher mag auch gestoppt oder gestartet werden.
2. "... wenn es in die Region von über 1000 aktive Timer geht."
Dann stellt sich mir die Frage, wieso 1000 aktive Timer? Willst du wirklich sagen, dass ein Kommando stime() für jedes Auftreten einen Timer erzeugt? Ist es nicht eher so, dass es 1000 Vergleichswerte gibt, anhand derer ein Timer geprüft wird?

Prüfen ist ein durchgehendes Element des eibPCs. Ständig wird etwas geprüft. Gehst du also davon aus, dass diese Prüfung nun mehr Rechenzeit verbrät, als irgend eine andere Prüfung?

Und wie sieht das dann bei allen anderen Kommandos mit Timerbezug (außer delay und after, wobei auch hier ein Timer ausreichen würde) aus? Hast du einen Schuldigen gefunden und nächste Woche kommen die nächsten drann?

Ob du das nun besser weißt, oder auch nicht.

Auch bei dieser Antwort hast du wieder die Rechenlast von stime() betont. Kein Wort davon, dass es 1. um die Häufung der Aktionen geht, die durch die daraus folgenden "gleichzeitigen" Events auftritt und 2. die teils unnötige Verarbeitung (Eventgetrieben vs Timerbasiert) geht.

Da ist nicht die Frage, ob ich es besser weiß, sondern du solltest es besser wissen.

Sollte der eibPC/Compiler wirklich so schlecht programmiert sein, wie du es darstellst, würde ich diese Probleme mal angehen, siehe auch find()!!!!

[enertegus]

Ist es nicht eher so, dass es 1000 Vergleichswerte gibt, anhand derer ein Timer geprüft wird?

Genau so ist es.

Und wie sieht das dann bei allen anderen Kommandos mit Timerbezug (außer delay und after, wobei auch hier ein Timer ausreichen würde) aus?

Da verhält es sich ähnlich.
Ich komme dann vielleicht auf 2000 Vergleiche, die abgearbeitet werden müssen. Das an sich ist nicht schlimm, aber die Systemlast steigt, weil in jeder Verarbeitung dann eben diese Liste durchgestöbert werden muss. Und die Message des Postings war: Lieber change() nutzen.

siehe auch find()!!!!

find() hat kein Problem: Die mehrfache Suche (im konkreten waren es wohl um die 200) eines Strings in einem 3k großen String benötigt bei jedem Rechner Zeit. Immer zu bedenken, dass das ja nicht im einem Thread läuft, sondern pro Zyklus ausgeführt werden muss, wenn es in einem if-Block gecoded wurde.

[saft6luck]

Da verhält es sich ähnlich.

Warum dann stime() herauspicken? Geht es nun um dieses Kommando oder um die "falsche" Herangehensweise? Klar, letzteres!

Dann aber bitte das Thema richtig aufarbeiten und entsprechend darstellen, dass ist meine Erwartungshaltung. Und nicht mal plötzlich ... huch da hatte einer oder zwei ein Problem ... ist vielleicht nicht so toll ... stime() an die Wand.

Das von dir dargestellte Problem ist nicht auf stime() beschränkt und auch nicht auf den WebServer. Es ist analog für alle Themen relevant, die kurzzeitige Lastspitzen erzeugen. Dein Beispiel ist nur ein Beispiel.

Ich komme dann vielleicht auf 2000 Vergleiche, die abgearbeitet werden müssen. Das an sich ist nicht schlimm, aber die Systemlast steigt, weil in jeder Verarbeitung dann eben diese Liste durchgestöbert werden muss. Und die Message des Postings war: Lieber change() nutzen.

Es geht nicht um Vergleiche, denn change() muss auch verglichen werden. Das ist kein Unterschied! (Sollen 2k Vergleiche eigentlich eine große Zahl sein?)

Wenn du die Zahl der Vergleiche anführst, müsstest du darauf hinweisen, gleiche Vergleiche (gleiche Bedingungen) zusammen zu fassen. Also z.B. alle stime(1) in ein if, alle stime(2) in eines ... dann kann es maximal 60 Vergleiche geben.

Gleiches wäre aber auch für change() gültig, oder?

find() hat kein Problem: Die mehrfache Suche (im konkreten waren es wohl um die 200) eines Strings in einem 3k großen String benötigt bei jedem Rechner Zeit. Immer zu bedenken, dass das ja nicht im einem Thread läuft, sondern pro Zyklus ausgeführt werden muss, wenn es in einem if-Block gecoded wurde.

Ich hatte schon vermutet, dass du bei find() kein Problem siehst.

Leider hat es ein Problem und das habe ich auch gezeigt.

Warum? Weil find() sogar bei einer "trivialen" Anwendung langsamer ist, als das umkopieren eines Strings.
Im besagten Fall ging es um max 1k, unterteilt in ca. 20 Substrings, teilweise unter 10 bytes lang!

Die Suche des 1. Auftretens eines einzelnen Zeichens ist ok(?)
Das 2. Zeichen dauert aber bereits länger als den 1. Teil des Strings abzuschneiden (kopieren+umkopieren) und im Rest wieder das 1. Auftreten zu finden.

Und da sagst du find() habe kein Problem?