gelöst: Blockly/JS Systemlast bei "debug output (debug)"
-
Frage an die Profis:
Der Blockly-Block:
erzeugt den JS-Code (ermittelt durch Umschaltung im Blockly-Editor auf JS-Ansicht):console.debug('Test');Nach meinem bisherigen Verständnis erzeugt dieser Befehl nur dann eine Ausgabe im Log, wenn die javaskript-Instanz auf "debug" gestellt wurde. Allerdings sehe ich keinen Grund, warum der Befehl selbst nicht immer ausgeführt wird. Ich könnte mir jetzt zwei Varianten vorstellen, wie das real im Hintergrund abläuft:
- Bei der Ausführung des Befehls wird geprüft, ob die Instanz auf "debug" steht und nur falls dies zutrifft, wird ins Log geschrieben. In diesem Fall belastet (auch wenn dies vermutlich nur gering ist) allein das Vorhandensein des Befehls in einem Skript das System bei Ausführung des Skripts.
- Da die Instanz beim Setzen auf "debug" neu startet und (wenn ich das hier im Forum richtig verstanden habe) alle Skripte nach einem Instanzneustart neu übersetzt/kompiliert werden, könnte es sein, daß dieser debug-Befehl im Übersetzungs-/Kompilierungsergebnis nur enthalten ist, wenn die Instanz auch auf "debug" steht. Das wäre dann nach meinem Verständnis so ähnlich, wie das andere Programmiersprachen/Compiler via Compiler-Optionen handhaben würden. In diesem Fall würde der Befehl im "Normalfall" (also wenn die Instanz nicht auf "debug" steht) keine zusätzliche Systemlast erzeugen, weil er dann gar nicht vorhanden wäre und damit auch nicht ausgeführt werden würde.
Weiß jemand, ob und falls ja welche der beiden genannten Möglichkeiten zutreffen?
Hintergrund meiner Frage:
Erzeugt man Systembelastung durch "intensives" verwenden des o. g. Blockly-Blocks? -
@andersmacher Hm, gar keine Antwort. Da hatte ich tatsächlich nicht mit gerechnet. Ist meine Frage zu speziell oder unsinnig?
Ich frage noch ´mal anders:
Wenn Ihr etwas größere Skripte schreibt, in denen Ihr beim/zum Testen auch viele debug-Anweisungen drin habt (vermutlich dann ja erstmal debug output "info" (damit man die Ausgaben im Log gleich angezeigt bekommt), schmeißt Ihr die dann, wenn das Skript wie gewünscht läuft, raus oder stellt Ihr sie auf debug output "debug" um, damit das Log übersichtlich bleibt und man später, falls es doch nochmal Kontrollbedarf für das Skript gibt, dies einfach durch Setzen der javascript-Instanz auf debug lösen kann?Falls Ihr die debugs nicht nur von "info" auf "debug" umstellt, sondern wirklich rausschmeißt, warum?
Weil Systemlast-Bedenken wegen zuviel debug-Anweisungen bestehen?Gibt es da eine "good/best practice"? Ich habe dazu via Suchmaschinen seltsamerweise gar nichts gefunden.
-
@andersmacher sagte in Blockly/JS Systembelastung durch "debug output (debug)":
vermutlich dann ja erstmal debug output "info
nöö, debug kommt immer unter dem Editorfenster ohne das iobroker log aufzublähen.
-
@andersmacher sagte: schmeißt Ihr die dann, wenn das Skript wie gewünscht läuft, raus
Man kann Blöcke auch deaktivieren. Dann werden sie nicht kompiliert.
-
Danke für Eure Rückmeldungen!
@homoran Das kann ich so nicht bestäigen. Beim @andersmacher läuft das mal wieder anders
:
ergibt im Protokoll (das ist doch das ioBroker-Log - oder?) nach Skriptstart:
@paul53 Ja, das ist mir bekannt, aber dann muß man sie (ggf. ja viele) auch alle wieder einzeln aktivieren, wenn man sie doch wieder braucht. Mit debug output "debug" und Instanz auf "debug" stellen scheint mir das einfacher und eigentlich hatte ich bisher auch geglaubt, daß das dafür auch gemacht ist.
-
@andersmacher sagte in Blockly/JS Systembelastung durch "debug output (debug)":
Bei der Ausführung des Befehls wird geprüft, ob die Instanz auf "debug" steht und nur falls dies zutrifft, wird ins Log geschrieben.
So ist das richtig. Da findet halt jedes Mal ein Vergleich statt ob das konfigurierte Level zum Level der Meldung passt.
In diesem Fall belastet (auch wenn dies vermutlich nur gering ist) allein das Vorhandensein des Befehls in einem Skript das System bei Ausführung des Skripts.
Da würde ich mir um die paar Auswertungen in deinen Scripts keine Sorgen machen, da alle Adapter mit hunderten von diesen Debug-Zeilen (welche meistens dank höherem Log Level ins leere laufen) das System "belasten". Und davon merkst Du in der Regel ja auch nichts.
-
@andersmacher
Wegen ein paar Anweisungen würde ich mir keine Gedanken machen.
Der Befehl wird allerdings schon ausgeführt nur irgendwann sieht der JavaScript Adapter, das da nix offen ist wo er was ausgeben kann bzw. Die Iobroker logging Komponente filtert es dann aus, aber davon erfährt der JavaScript Adapter dann nix mehr davon. -
@haus-automatisierung und @OliverIO Auch Euch einen Dank!
Daß das (für/in EIN/EINEM Skript) nicht VIEL aus macht, dachte ich mir schon ("auch wenn dies vermutlich nur gering ist"). Aber @haus-automatisierung schreibt ja auch:... da alle Adapter mit hunderten von diesen Debug-Zeilen (welche meistens dank höherem Log Level ins leere laufen) das System "belasten"...
Ich habe ioBroker als sehr durchdachtes/optimiertes System kennengelernt und daher eigentlich auf meinen Fall 2) getippt. Denn wozu Anweisungen beim Kompilieren im Code belassen, die (bei dem Log-Level mit dem / für den sie kompiliert werden) ohnehin nichts bewirken?
Keine Ahnung, ob das dann ein zu großer Prüfaufwand für den Kompiler wäre. War halt so ein Gedanke, der mir kam, als ich in einem etwas größeren Skript zum 1. Mal etwas "verschwenderischer" mit debugs war.
Nochmals Danke an alle für die Klärung!
-
@andersmacher sagte in Blockly/JS Systembelastung durch "debug output (debug)":
Denn wozu Anweisungen beim Kompilieren im Code belassen
- JavaScript wird nicht kompiliert, sondern interpretiert (Das ist nicht 100% der richtige Terminus, aber für die Erklärung völlig egal). Jedenfalls gibt es keine "Binärdaten" die irgendwo auf der Festplatte liegen. Es gibt nur den Quellcode und kein "Kompilat" (als Datei), wie das z.B. bei C++ der Fall ist, wo man dem Präprozessor sagen kann, dass bestimmte Teile ausgelassen oder "leer" implementiert werden sollen.
- Könntest Du ja jederzeit das Loglevel einer Instanz umstellen und somit die Meldungen sehen wollen. Das würde ja gar nicht möglich sein, wenn diese gar nicht in den Binärdaten vorhanden wären (welche es bei JavaScript ja eh nicht gibt in der Form)
- Macht das fast jede Software so, welche ich kenne. Du kannst z.B. eine SSH-Verbindung auch mit
ssh -vvv <nutzer>@<host>starten und bekommst richtig viele Ausgaben, welche Du sonst gar nicht siehst. Weil Du das verbose-Level erhöht hast. Und da wird ssh ja auch nicht neu kompiliert - das würde ja viel länger dauern und mehr Ressourcen brauchen, als kurz ein paar Dinge zu prüfen und zu überspringen...
Kurzum: Mach Dir keinen Stress wegen den paar Auswertungen. Das wird Dein System schon nicht ans Limit bringen oder für eine viel höhere Auslastung sorgen.
-
@haus-automatisierung
Zu 1. und 2.
Daß eine Skriptsprache (normalerweise?) nicht kompiliert wird, war mir bekannt bzw. so dachte ich das immer, bis ich in einem Artikel/Thread oder was auch immer das war (Das war zu dem Thema, daß man mit Skripten unter common vorsichtig sein sollte) gelesen habe, daß im ioBkroker die Skripte bei Start der javascript-Instanz immer neu übersetzt (=kompiliert?) werden. Hatte mich gewundert, aber ich hab´s geglaubt, weil ich daraufhin im I-Net auch Artikel gefunden habe, die besagen, daß z. B. Browser JS-Code kompilieren.Zu 3. sage ich nichts, weil ich mich damit nicht auskenne.
-
@haus-automatisierung sagte: JavaScript wird nicht kompiliert, sondern interpretiert
Node.js verwendet einen JIT-Compiler (V8).
-
@paul53
V8 kommt ursprünglich aus dem chromium Projekt und ist Bestandteil von chrome und edge
https://de.wikipedia.org/wiki/V8_(JavaScript-Implementierung)?wprov=sfti1
Das selbe (wie man es auch immer nennt) passiert im Browser auch. -
@oliverio sagte: V8 ... ist Bestandteil von chrome und edge
... und von Node.js.
-
@paul53 ja genau
-
@andersmacher sagte in Blockly/JS Systembelastung durch "debug output (debug)":
ergibt im Protokoll (das ist doch das ioBroker-Log - oder?) nach Skriptstart:
ist ja auch info und nicht debug
-
Ich setze das Thema ´mal auf gelöst, lese aber gern noch mit, wenn Ihr hier weitere Infos einbringt.
-
@paul53 sagte in gelöst: Blockly/JS Systemlast bei "debug output (debug)":
Node.js verwendet einen JIT-Compiler (V8).
Ja, das ist richtig - war nicht 100% korrekt erklärt. Tut aber auch nichts zur Sache für die Erklärung und solche Begriffe verwirren den TO bei der Fragestellung ja nur (noch mehr). Habe die Antwort noch einmal editiert.
-
@andersmacher sagte in gelöst: Blockly/JS Systemlast bei "debug output (debug)":
daß im ioBkroker die Skripte bei Start der javascript-Instanz immer neu übersetzt (=kompiliert?) werden. Hatte mich gewundert
Wo hast Du das gelesen? Es kommt drauf an, was man nutzt. TypeScript z.B. ist wieder eine Ausnahme und muss erstmal vom JavaScript-Adapter in "normales JavaScript" übersetzt werden. Kompilieren ist dafür aber der falsche Begriff.
-
@haus-automatisierung Ich meine, es war dieses Jahr hier im Forum. Wenn ich noch genau wüßte, wo ich´s gelesen habe, hätte ich den Link eingefügt.
@andersmacher sagte in gelöst: Blockly/JS Systemlast bei "debug output (debug)":
Da die Instanz beim Setzen auf "debug" neu startet
Habe gerade festgestellt, daß es jetzt? (hatte nicht in Erinnerung, daß das schon immer so war) eine Option gibt, den debug-Level auch ohne Instanzneustart zu ändern:
für diesen Fall trifft Dein Hinweis dann natürlich voll zu:
@haus-automatisierung sagte in gelöst: Blockly/JS Systemlast bei "debug output (debug)":
Könntest Du ja jederzeit das Loglevel einer Instanz umstellen und somit die Meldungen sehen wollen.
Was dabei für mich noch offen bleibt:
Wenn man den debug-Level der Instanz auch ohne Neustart ändern kann, warum macht man das dann nicht immer so? Suggeriert für mich irgendwie, daß es auch einen Nachteil hat.@Homoran
@Homoran sagte in gelöst: Blockly/JS Systemlast bei "debug output (debug)":nöö, debug kommt immer unter dem Editorfenster ohne das iobroker log aufzublähen.
Entschuldige bitte, ich hatte Dein "debug" als den Befehl und nicht als die Log-Stufe verstanden. Das war wohl eine Fehlinterpretation von mir.
Allerdings taucht das debug im Editor unter dem Skript ja auch nur dann auf, wenn die Log-Stufe der Instanz zur Log-Stufe des debug-Befehls paßt und in diesem Fall landets auch immer im Protokoll. Das dann als "aufblähen" zu bezeichnen war von mir nicht korrekt, denn das will man in dem Moment ja dann auch bewußt so. Wenn man auf "info" zurückstellt, würde ein 'debug output "debug"' das Protokoll nicht mehr vergrößern.
Wenn ich das alles für mich nochmal zusammenfasse bin ich bei:
- Eine Debug-Anweisung im Skript ist da auch bei der Ausführung und zwar egal, für welchen Level sie definiert wurde und auf welchem Debug-Level die JS-Skript-Instanz steht.
- Der "nackte" debug-Befehl wird daher immer ausgeführt und nimmt eine sehr kurze CPU-Zeit in Anspruch.
- Das wird allgemein tolleriert/als unkritisch angesehen, weil die Vorteile einer später jederzeit möglichen Nachverfolgung der Skript-Funktionalität überwiegen.
-Ob die debug-Anweisung auch eine (sichtbare) Reaktion nach sich zieht (z. B. Ausgabe im Log), hängt vom debug-Level des Befehls und der Log-Stufe der Instanz ab.
