Calendar Modul: lange Ladezeit und 98% CPU

[Dr. Boris Neubert]

Neuer Versuch mit der Bitte um Test.

[Amenophis86]

Es scheint ein bisschen besser geworden zu sein, aber immer noch nicht nonblocking. Problem ist, dass ich irgendwie beim starten von fhem über nytprof sehe was passiert. Es startet FHEM im nytprof modus, aber bringt mich direkt wieder zurück in die normalen konsolen Befehle. Letztes mal konnte hat die Aussgabe mir genau gezeigt was passiert und auch die Zeiten genannt, wie lange das update des Kalender gebraucht hat.

Ich habe jetzt nochmal ein prof mit dem großen Kalender gemacht, vielleicht hilft dieser dir weitere Probleme zu erkennen. Würde sie dir gerne per Mail schicken, da mir nicht bewusst ist, ob sich aus dieser Datei die URL für den Kalender auslesen lässt. Und die möchte ich nicht öffentlich machen

[Dr. Boris Neubert]

Danke fürs Testen.

Du kannst mir das Profil gerne per E-Mail schicken.

Wirklich nichtblockierend wäre es nur, wenn ich auch das Parsen in einen separaten Thread auslagern würde. Das ist mir derzeit zu aufwendig.

Viele Grüße
Boris

[Dr. Boris Neubert]

Hallo,

die Analyse zeigt, dass es bei Dir dieselben Stellen sind wie bei mir, wo die meiste Zeit vergeht. Diese bekomme ich nicht wegoptimiert. Es sind das die Zerlegung der Zeilen mit einem regulären Ausdruck und die String-Vergleiche ind addproperty().

Besser geht es also leider nicht ohne Hintergrundverarbeitung. Ich habe diese Version jetzt eingecheckt.

Ich habe mir eine mögliche Hintergrundverarbeitung mit Blocking angeschaut. Ich fürchte Race Conditions. Vielleicht gebe ich mich in nächster Zeit mal daran.

Viele Grüße
Boris

[Amenophis86]

Ich weiß zwar nicht was Race Conditions sind, aber ich danke dir fürs Kümmern und würde mich freuen, wenn irgendwann komplett nonBlocking kommt. Wenn man dich unterstützen kann, dann einfach Bescheid geben. Programmieren fehlt mir aber leider das Wissen

[Dr. Boris Neubert]

https://de.wikipedia.org/wiki/Race_Condition

nonBlocking wird durch Nebenläufigkeit zweier Programmstränge herbeigeführt: FHEM läuft weiter, während der Kalender im Hintergrund geholt und geparst wird. Zudem werden auch noch per Timer asynchron beim Erreichen bestimmter Uhrzeiten Events erzeugt und dann der Timer neu gestellt. Sowohl im Hauptstrang als auch in den Nebensträngen werden Timer gesetzt und der Kalender manipuliert. Das ist sehr schwer zu überblicken und ich werde mit sowas sie Semaphoren arbeiten müssen, das sind Merker, die den Eintritt in bestimmte Codepassagen verhindern, wenn diese Codepassage gerade in einem anderen Strang (nebenläufig) ausgeführt wird.

[Amenophis86]

liest sich kompliziert aber ich denke, dass ich verstanden habe was das Problem ist. Bleibt mir nur zu hoffen, dass du es programmtechnisch lösen kannst. Aber lese auch raus, dass es nicht von heute auf Morgen gehen wird. Daher freue ich mich, wenn ich wieder von dir höre und es hier was neues geben wird

[slupus]

Wow, vielen Dank Boris für diese Optimierung! Leider hat die Forumsbenachrichtigung nicht funktioniert, sodass ich erst beim Update von der Optimierung erfahren habe.
Der reine Reload meines Kalenders dauert nur noch knapp 2 Minuten, vorher weit über 10 Minuten. Das ist wirklich fantastisch

Wie ich gelernt habe, sind die Regeltermine das Problem. Davon habe ich sehr viele.

Vielen Dank und viele Grüße
Sören

[Praktiker]

Danke für die Optimierung,

bei meinem Kalender nur ca. 1/3 der Zeit.
Leider gehen seit dem Update die Termine mit den Emojis nicht mehr.
Lässt sich das wohl noch fixen ?
Das 1. Bild ist aus dem Tablet ui (Sieht im Web interface genauso aus)
Das 2. Bild ist der Original Kalender (Google)
Vor dem Update sah es besser aus....

Grüsse
Praktiker

[Dr. Boris Neubert]

Hallo,

freut mich,dass die Optimierung einiges gebracht hat.

@Praktiker: die Emojis wurden vor dem Update alle angezeigt und jetzt fehlen welche?

Kannst Du mir eine ICS-Datei schicken zum Reproduzieren? Könnte ein Problem mit Kodierung sein.

Grüße
Boris

[Praktiker]

Hallo Boris,

ja alle bis auf das letzte Emoji,  in dem Original eine Sonne.
Hab mal einen Kalender erstellt und exportiert.
Grüsse
Praktiker

[Dr. Boris Neubert]

ja alle bis auf das letzte Emoji,  in dem Original eine Sonne.

Testdaten waren sehr hilfreich.

Habe es gefixt.

Das Problem ist der reguläre Ausdruck \R, der alle nach Unicode zulässigen Zeilenenden matcht. Er zersemmelt die Emojis. Ich habe daher die defensivere Variante gewählt, die alle klassischen Möglichkeiten von Zeilenende bei Dos, Windows, Unix und Mac abdeckt.

Eingecheckt. Heute per SVN und morgen auch per Update verfügbar.

[Praktiker]

Danke!

[Dr. Boris Neubert]

Hallo,

anbei die erste Version des Kalendermoduls, die die iCalendar-Datei asynchron parst. Während des Parsens ist FHEM damit voll verfügbar.

Achtung: es wird eine neue Version von FHEM/SubProcess.pm benötigt. Diese ist morgen früh per Update verfügbar oder kann aus dem SVN-Repo bezogen werden.

Gute Nacht
Boris

Edit: Anhang mit Testmodul gelöscht.

[slupus]

Hallo Boris,
habe mir die Änderungen per Update geholt.
Aufgefallen ist mir, dass debug Meldungen ins Log geschrieben werden. Die CPU Auslastung lag bei knapp 98% während des Updates des Kalenders. Dauer in etwa gleich lang wie vor dem Update.
Liegt vielleicht aber auch an meinem Pi1.
Grüße Sören