Performance CommandDefine/CommandDelete vs. internal Timer

[KernSani]

Hallo zusammen,

mir ist gerade aufgefallen, dass TRX_LIGHT auf meinem Raspi etwa 0,5 Sekunden braucht, wen bei laufendem on-for-timer ein weiteres on-for-timer geschickt wird. Ins Modul geguckt, festgestellt, dass on-for-timer über sowas

Code Auswählen Erweitern

define <bla>_timer at 00:00.30 set <bla> off
realisiert ist. Wenn bei laufendem on-for-timer ein weiteres on-for-timer kommt, wird ein CommandDelete auf das at gemacht (und das scheint Zeit zu kosten). Bevor ich jetzt einen patch bastle: Ist zu erwarten, dass ich mit InternalTimer deutliche Performance-Verbesserungen erziele?

Danke,

Grüße,

Oli

[CoolTux]

Hallo Oli,

Schau Dir Spaßenshalber die Funktion CommandDelete an. Eventuell siehst Du da dann schon was.
Ich denke aber eher das Du im at Code schlauer wirst. Denn da steht ja dann was genau passiert wenn ein Device gelöscht wird. Ich behaupte mal ohne es genau zu wissen daß dort auch nur RemoveInternalTimer aufgerufen wird. Aber man kann ja mal nachschauen.
Statt einem Patch mit InternalTimer an zu bauen würde ich lieber gleich SetExtension einbauen.


Grüße

[KernSani]

Hi Leon,

danke für den Hinweis mit SetExtensions - hätte ich selbst dran denken müssen. Das hat mir auch das richtige Stichwort für die Forumssuche gegeben, den Patch gibt's nämlich schon: https://forum.fhem.de/index.php/topic,80760.msg732008.html#msg732008 Mit leichten Anpassungen läuft das jetzt (unter 0.5 Sekunden - genau habe ich's nicht nachgemessen)

Grüße,

Oli

[rudolfkoenig]

Bevor ich jetzt einen patch bastle: Ist zu erwarten, dass ich mit InternalTimer deutliche Performance-Verbesserungen erziele?

"define X" erzeugt ein Event, und die Reaktionen darauf koennen (jenachdem, wer was mit den Events anstellt), auch laenger dauern. InternalTimer erzeugt keine Events, ist also sicher schneller, ist aber auch kompizierter zu handhaben (d.h. anschauen/loeschen/etc)

[KernSani]

Danke, Rudi. Mein Eindruck war eher, dass (in meinem Fall) das delete (und das darauf folgende event) einen Rattenschwanz an hinter sich her gezogen hat. Umbau auf setExtensions hat das aber gelöst. (die TRX-Module werden nicht mehr wirklich "ge-maintained", oder?)

[rudolfkoenig]

die TRX-Module werden nicht mehr wirklich "ge-maintained", oder?

Nich wirklich. Der Maintainer hat sich seit ca 5 Monaten nicht mehr im Forum gezeigt, und die Module wurden seit knapp 2 Jahren nicht angefasst.
War das eine indirekte Meldung fuer die Uebernahme der Module? Wenn ja, ich sehe da keine Probleme, wir sollten nur Formhalber den alten Maintainer benachrichtigen.

[KernSani]

War das eine indirekte Meldung fuer die Uebernahme der Module? Wenn ja, ich sehe da keine Probleme, wir sollten nur Formhalber den alten Maintainer benachrichtigen.

Jein... Wenn es sich darauf beschränkt, die Module an aktuelle FHEM-Standards anzupassen (also sowas wie SetExtensions zu verwenden oder Commandref anpassen) dann ja. Wenn aber erwartet wird, dass die Module weiterentwickelt werden (also z.B. neue Protokolle implementiert werden) fehlen mir Zeit und (zumindest aktuell) Wissen.

[rudolfkoenig]

Das waere immer noch deutlich besser, als der aktuelle Zustand.
Vielleicht kannst du es als KernSani/orphan uebernehmen, um zu zeigen, dass du kein Problem hast es weiterzugeben.

[KernSani]

Hi Rudi,
da mir an anderer Stelle schon spontan Unterstützung angeboten wurde, würde ich mich der Waisen annehmen, bis sich bessere Pfleeltern finden (oder ich gewinne die Kleinen so lieb, dass ich sie nichtmehr hergeben möchte..)
Aber bitte keine Wunder erwarten;-)


Kurz, weil mobil...