Optimierungsvorschlag "HandleTimeout()" in fhem.pl

[KernSani]

Für perfmon kann ich das nicht feststellen. Woher stammt die Aussage ? - bzw, to-dos ?

keine Todos aus meiner Sicht... apptime (in der alten Version) baut die (neuen) InternalTimer nicht ab. Wenn Freezemon, Perfmon oder andere Module aktiv sind, die viele internal Timer erzeugen verstärkt sich das Problem natürlich.

Ich habe gerade mal ein bisschen mit Ansgars Version von apptime und der originalen Version getestet - das geht recht schnell... Neben Freezemon läuft alle zwei Sekunden ein at mit einem Perl-Sleep:
Alte apptime - nach wenigen Sekunden liefert

Code Auswählen Erweitern

{ join("\n", map {$intAtA[$_]->{FN}} grep { !$intAt{ $intAtA[$_]->{atNr} } } (0..@intAtA)) } einige Zeilen mit freezemon und meinem at und zwischendrin ein paar andere
Ansgars apptime - auch nach 10 Minuten liefert

Code Auswählen Erweitern

{ join("\n", map {$intAtA[$_]->{FN}} grep { !$intAt{ $intAtA[$_]->{atNr} } } (0..@intAtA)) } einfach: nichts...

Ich lasse das jetzt mal noch ein bisschen weiterlaufen.

@Ansgar: Dein Freezemon-Code sieht auch gut aus.

[rudolfkoenig]

Für perfmon kann ich das nicht feststellen. Woher stammt die Aussage ? - bzw, to-dos ?

Ich stehe immer noch zu meiner vorherigen Aussage:

Soweit ich sehe, startet perfmon nur einen Timer einmal die Sekunde, provoziert also eher das Problem

[herrmannj]

ich habe nicht alles mitverfolgt. Ist perfmon schuld (und muss geändert werden) oder opfer ?

[noansi]

Hallo Zusammen,

den perfmon code finde ich nicht im SVN, ist wohl rausgefallen oder versteckt?!?

Wenn er nur Timer normal mit InternalTimer startet, wie freezemon, und mit RemoveInternalTimer löscht, dann ist er nur beschleunigendes Opfer bei gleichzeitiger Nutzung von apptime aus dem SVN.

apptime ersetzt HandleTimeout() aus fhem.pl und behandelt die Timerwarteschlange nach altem %intAt. Das geht dann natürlich schief, da die behandelten Timer nicht aus der neuen @intAtA Warteschlange gelöscht werden womit das array dann immer weiter anwächst.

Das habe ich in dem apptime hier https://forum.fhem.de/index.php/topic,81365.msg772582.html#msg772582 umgestellt auf @intAtA Behandlung, wie Rudolf es in fhem.pl macht. Martin müsste es nur noch im SVN einpflegen.
In dem Apptime ist auch noch ein nicht aktiver Debugcode zur Prüfung der Array Sortierung nach Zeit bei jedem HandleTimeout() Aufruf drin, falls mal ein Verdacht auf falsche Sortierung aufkommen sollte. Ansonsten habe ich mich mit Ergänzungen oder Anpassungen zurück gehalten. 

In freezemon wurde das von Rudolf noch erhaltene %intAt nach "feuerbereiten" Timern in den "nächsten 10 Sekunden" durchsucht und das Ergebnis sortiert, um es dann zu verarbeiten.
Da @intAtA nun aber ohnehin nach Zeit sortiert ist, kann freezemon mit meinem Änderungsvorschlag oben sogar von der Timerumstellung profitieren.
Mehr habe ich mir zu freezemon aber erst mal nicht angeschaut.

Gruß, Ansgar.

[KernSani]

PERFMON gibt es glaube ich nur via Forumslink, der fasst die Timer aber nicht an, sondern erzeugt nur viele, wirkt also als Brandbeschleuniger.

Die auf intAtA angepasste Freezemon-Version läuft bei mir seit knapp 24 Stunden stabil (inkl. angepasster apptime). 

[DS_Starter]

Für die angepasste apptime kann ich das auch bestätigen.

VG

[KernSani]

Freezemon ist jetzt mit neuer intAtA eingecheckt.

[noansi]

Hallo Zusammen,

Martin hat nun auch apptime auf @intAtA angepasst.
Danke!

Gruß, Ansgar.