Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Andersmacher]

@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!

[haus-automatisierung]

@andersmacher sagte in Blockly/JS Systembelastung durch "debug output (debug)":

Denn wozu Anweisungen beim Kompilieren im Code belassen

1. 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.
2. 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)
3. 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.

[Andersmacher]

@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.

[paul53]

@haus-automatisierung sagte: JavaScript wird nicht kompiliert, sondern interpretiert

Node.js verwendet einen JIT-Compiler (V8).

[OliverIO]

@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.

[paul53]

@oliverio sagte: V8 ... ist Bestandteil von chrome und edge

... und von Node.js.

[OliverIO]

@paul53 ja genau

[Homoran]

@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

[Andersmacher]

Ich setze das Thema ´mal auf gelöst, lese aber gern noch mit, wenn Ihr hier weitere Infos einbringt.

[haus-automatisierung]

@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.

[haus-automatisierung]

@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.

[Andersmacher]

@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.