UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[uwe72]

@jey-cee

Ok ;-)

Was wäre eine Optimierung, weniger kleinere Global-Scripte und dafür wenige große? D.h. übertrieben gesagt, alle global-Scripte in 1 Global Script überführen?

Als früherer Java-Entwickler tue ich mich sowieso schwer mit dieser global/common-Architektur. Würde gerne Klassen/Funktionen einfach einbinden wollen in meine Scripte.

[Jey Cee]

@uwe72 sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

D.h. übertrieben gesagt, alle global-Scripte in 1 Global Script überführen?

Naja wenn du jetzt 2 Globale Scripte hast die jeweils 50% deiner Scripte nutzen, dann würde ein großes 100% deiner Scripte betreffen. Das wäre also Kontraproduktiv.
Du solltest dir Überlegen ob du wirklich alle Globale Scripte brauchst und in welchen Scripten.
Seit einer weile kann man auch mit messageTo Nachrichten zwischen Scripten austauschen.
Das sollte man bevorzugen.

[uwe72]

Generell Danke schon einmal für deine Antworten!!

@jey-cee said in TypeScript, viele common/global Scripte --> CPU am Anschlag:

Naja wenn du jetzt 2 Globale Scripte hast die jeweils 50% deiner Scripte nutzen, dann würde ein großes 100% deiner Scripte betreffen. Das wäre also Kontraproduktiv.

Würde aber bedeuten, nur dass ich es besser verstehe,

Angenommen ich habe 10 Common-Scripte und 3 Global Scripte (g1,g2,g3):
Ändere ich was an "g1" würde nur die neue Inhalt von "g1" in den 10 common-Scripten aktualisiert werden. Die gleichbleibenden Inhalte von g2 und g3 würden in den common-Scripten nicht angepasst werden? Vermutlich würde es dann eher helfen die Anzahl der common-Scripte zu reduzieren. Da habe ich sehr viele kleine.

Generell:
Ich habe eben beispielsweise in den global scripten in einem Array alle Devices hinterlegt mit einigen Zusatzinformationen (Etage, Raum,.... u.v.m.). In den Common-Scripten möchte ich auf diese Arrays zugreifen. Zudem sind in global viele Funktionen die ich immer wieder benötige und ich möchte Code nicht immer duplizieren.

Ich habe das mit dem messageTo noch nicht ganz verstanden. Ich bräuchte aber eher was getMessageFrom ;-) D.h. Auslöser sind ja meine common-Scripte wo ich von anderer Stelle (aktuell in global) was benötige.

[uwe72]

Bitte Kommentar löschen

[paul53]

@uwe72 sagte: common-Scripte zu reduzieren. Da habe ich sehr viele kleine.

Das ist offenbar zusammen mit

@uwe72 sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

in den global scripten in einem Array alle Devices hinterlegt mit einigen Zusatzinformationen (Etage, Raum,.... u.v.m.).

das Problem. In jedes noch so kleine common-Script wird das Array kompiliert.

@uwe72 sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

in global viele Funktionen die ich immer wieder benötige

Genau dafür ist "global" gedacht, da Funktionen nur kompiliert werden, wenn sie im Skript aufgerufen werden.

[OliverIO]

@uwe72
Das allerbeste wäre alles in ein lokales NPM Paket zu legen und das dann in die Konfiguration des Java Skript Adapters zu packen.
Allerdings weiß ich nicht, ob die Konfigurationsseite mit lokalen NPM Pfaden umgehen kann.
https://www.stefanjudis.com/today-i-learned/npm-install-supports-local-packages/

[GombersIOB]

@jey-cee said in TypeScript, viele common/global Scripte --> CPU am Anschlag:

die müssen auch alle neu Kompiliert werden wenn sie in Typescript geschrieben sind

Hieße doch, sie in JavaScripts zu transformieren könnte eine Lösung sein?

[Jey Cee]

@gombersiob das würde zwar die Last reduzieren, ja, aber nur bedingt da dennoch alle Scripte neu gestartet werden.

[GombersIOB]

@jey-cee said in TypeScript, viele common/global Scripte --> CPU am Anschlag:

da dennoch alle Scripte neu gestartet werden

Nur zu meinem Verständnis:
Jedesmal wenn ich eine Script (common) verändere, werden alle anderen Scripte auch neu gestartet? Ich verstehe, wenn ein global geändert wird, dass das notwendig ist, aber beim common?
Aber wie dem auch sei. Ich könnte mir vorstellen, dass das Kompilieren einen Großteil des CPU-Aufwands bedeutet. Wenn er also (ich schieße einfach mal aus dem Bauch eine Zahl) 50% spart, würde ihm das vermutlich helfen?

[GombersIOB]

@gombersiob
Sorry, habe den ersten Beitrag jetzt nochmal gelesen. Es ging ja tatsächlich um das Ändern der globalen Scripte.

[OliverIO]

@gombersiob sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

@jey-cee said in TypeScript, viele common/global Scripte --> CPU am Anschlag:

die müssen auch alle neu Kompiliert werden wenn sie in Typescript geschrieben sind

Hieße doch, sie in JavaScripts zu transformieren könnte eine Lösung sein?

Jein, wird es durch den typescript transpiler ja sowieso
Vorteil ist, das Pakete für sich kompiliert werden und erst neu kompiliert werden. Wenn es Änderungen gibt.

Ja, die Iobroker Skripte müssen neu gestartet werden.
Dann liegt aber der Performance schlucker nicht im kompilieren sondern an den Aktivitäten der Skripte selbst und bei jedem Neustart one Änderung oder nicht, geht die Performance weg.

Soweit ich es verstanden habe, werden die Common und global Skripte einfach vor jedes Skript kopiert.

[Homoran]

@oliverio sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

werden die Common und global Skripte einfach vor jedes Skript kopiert.

doch nicht common!

[GombersIOB]

@oliverio said in TypeScript, viele common/global Scripte --> CPU am Anschlag:

Ja, die Iobroker Skripte müssen neu gestartet werden.
Dann liegt aber der Performance schlucker nicht im kompilieren sondern an den Aktivitäten der Skripte selbst und bei jedem Neustart one Änderung oder nicht, geht die Performance weg.

Aber die Scripte machen doch in der Regel nichts beim Neustart. Meine haben eigentlich alle einen Trigger, die laufen nicht einfach so los.

Soweit ich es verstanden habe, werden die Common und global Skripte einfach vor jedes Skript kopiert.

Die "Common"-Scripte sind ja die laufenden Scripte. Es werden, wie ich hier lerne die "Global"-Scripte vor jedes Common-Script kopiert.

[Homoran]

@gombersiob sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

Aber die Scripte machen doch in der Regel nichts beim Neustart

doch! sie weden kompiliert

[Homoran]

@gombersiob sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

die "Global"-Scripte vor jedes Common-Script kopiert.

auch vor alle Skripte, die im Wurzelverzeichnis liegen

[paul53]

@homoran sagte: auch vor alle Skripte, die im Wurzelverzeichnis liegen

... oder in jeder anderen Gruppe als "global".

[Armilar]

@homoran sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

Aber die Scripte machen doch in der Regel nichts beim Neustart

doch! sie weden kompiliert

Aber nur wenn es Änderungen gibt...

Ansonsten wird die Version aus dem Cache genutzt.

[paul53]

@armilar sagte: Ansonsten wird die Version aus dem Cache genutzt.

Das betrifft anscheinend den Precompiler TypeScript --> Javascript.
Skripte werden bei jedem Neustart kompiliert, da beim Stoppen der RAM freigegeben wurde.

[uwe72]

Ich habe aus ca. 40 (kleineren) Common-Scripte ca. 25 (größere) gemacht und von 8 global Scripten auf 5 reduziert.

Ich laufe nun zumindest nicht mehr in das CPU-Problem rein. Das Speichern nach dem Ändern eines Global-Script dauert nun ca. 5 Minuten.

Übrigens, das Ändern von Common-Scripten ist nie ein Problem, auch vor der "Optimierung" nicht.

[uwe72]

Generell mache ich sehr viel mit Scripten und stoße aktuell an Grenzen mit den Rahmenbedingungen:

• TypeScript
• ca. 40 common-Scripte
• ca. 5-8 global-Scripte (mit teilweise bis zu 3000 Zeilen Code)

Ich spiele in einer anderen ioBroker-Umgebung mit dem Thema "messageTo" herum mit dem Ziel ganz auf global-Scripte verzichten zu können.

Ist ein wenig ein konstruiertes Beispiel, aber ganze Klassen(-inhalte) bekommt man nicht verschickt, oder? Sondern vermutlich nur "primitive" Datentypen oder vermutlich json?

export class TestPosition {
    private threeQuarter:   number;
    private half:         number;
    private oneQuarter:     number;

    constructor(threeQuarter: number, half: number, oneQuarter: number) {
        this.threeQuarter = threeQuarter;
        this.half = half;
        this.oneQuarter = oneQuarter;
    }

    public getThreeQuarter() : number {
        return this.threeQuarter;
    }
    public getHalf() : number {
        return this.half;
    }
    public getOneQuarter() : number {
        return this.oneQuarter;
    }
}

//var data = "uwe";
var data = new TestPosition(10,20,30);

messageTo({ instance: 'javascript.0', script: 'script.js.common.Test2', message: 'message1' }, data, {timeout: 1000}, result =>
    console.log(JSON.stringify(result)));

//@ts-expect-error
onMessage('message1', (data, callback) => {
    console.log(`UWE !!! Received data: ${data}`); callback({ result: Date.now() });
    var my = data.getThreeQuarter();
    log("YIPIEEEEEEEEEEEEEEEEEE: " + my);
});

Error in callback: TypeError: data.getThreeQuarter is not a function