JavaScript-Engine - Welche Prozesse laufen parallel?

[Michael_K]

Hallo,

hat jemand mehr wissen als die Google Suche und Google AI, wo ich nachlesen kann, welche Prozesse bei einer JS-Engine parallel ausgeführt werden?

JavaScript is single threaded, ja. Wenn man echte parallele Bearbeitung möchte, muss man auf Web Worker zurückgreifen. Diese können aber sehr teuer sein, d.h. die Performance wird ggfs. nachteilig beeinflusst (da eine WebWorker-Instanz erstellen, Daten hin- und hersenden relativ viel Rechenzeit benötigte). Deshalb ist es manchmal besser, wenn die Dinge direkt im mainthread bearbeitet werden.

Aber nach meiner Kenntnis kann eine JavaScript-Engine gewisse Dinge parallel implementieren, d.h. es wird ein eigener Thread genutzt. Zum Beispiel ist es wohl so, dass sowohl in der Mozilla JS-Engine als auch die V8-Engine ein eigener Thread für fetch() requests getriggerter wird.

Gibt es eine Übersicht oder kann man ermitteln, ob gewisse Dinge von der JS-Engine in einem eigenen Thread abgearbeitet werden?

Hintergrund:

Ein großer Datensatz soll in der IndexedDB abgelegt werden. Ich stelle mir nun die Frage, ob es sinnvoll ist, den Datensatz im Mainthread in die Indexed DB zu schreiben, oder doch auf WebWorker zurückzugreifen (was den Arbeitsspeicher zusätzlich belastet, da die Daten zur Übersendung and den Worker geklont werden.)

Wenn ich jetzt wüsste, dass die JS-Engine sowieso das Schreiben in eine IndexDB in einen separaten Thread auslagert, könnte man es im Mainthread über einen asynchronen task und einem callback lösen.

Gibt es dazu irgendwo Information?

[Rolf B]

Hallo Michael_K,

grundsätzlich kannst du dir die Einführung zu IndexedDB bei MDN anschauen, ist englisch, aber eine deutsche KI Übersetzung ist aber vorhanden.

Danach ist IndexedDB grundsätzlich asynchron.

Rolf

[Michael_K]

Hallo Rolf,

Danach ist IndexedDB grundsätzlich asynchron.

Das bedeutet ja nur non-blocking. Aber es adressiert nicht die Frage, ob es von der JS-Engine wirklich parallel ausführt. Bei IndexedDB scheint es so, dass es gerade nicht wirklich parallel ist. Wird hier diskutiert

Auch die Google AI sagt, dass WebWorker zu verwenden sind, wenn man echte parallele Ausführung erreichen möchte. Nur das bedeutet eben auch, dass man Daten duplizieren muss, was den Arbeitsspeicher belastet, da der GC wohl die an einen Worker gesendeten Daten nicht unmittelbar freigibt.

Aber es müsste doch einen besseren Weg geben, um zu testen oder eine Suchmaschine zu befragen, ob eine async Aufgabe. Gerade im Zeitalter von Multicore CPUs ist es doch sinnvoll wenn möglichst alle CPU-Cores genutzt werden und schennler fertig ist.

Gruß

[JürgenB]

Hallo Michael,

Auch die Google AI sagt, dass WebWorker zu verwenden sind, wenn man echte parallele Ausführung erreichen möchte. Nur das bedeutet eben auch, dass man Daten duplizieren muss, was den Arbeitsspeicher belastet, da der GC wohl die an einen Worker gesendeten Daten nicht unmittelbar freigibt.

wo kommen denn die Daten her? Können die nicht im Worker erzeugt/verarbeitet werden?

Wieviele GB willst du denn an die Datenbank schicken? Evtl. ist der Datentransfer an den Worker ja garnicht so ein Problem.

Aber es müsste doch einen besseren Weg geben, um zu testen oder eine Suchmaschine zu befragen, ob eine async Aufgabe. Gerade im Zeitalter von Multicore CPUs ist es doch sinnvoll wenn möglichst alle CPU-Cores genutzt werden und schennler fertig ist.

Betriebssysteme haben so etwas wie eine Aktivitätsanzeige. Bei meinem Macbook geht die Anzeige auf fast 1000% hoch, es werden also 10 CPU-Kerne von 10 Workern gequält.

Die Aktivitätsanzeige zeigt auch die Speicherbelegung an.

Gruß
Jürgen

[Michael_K]

Hallo Jürgen,

Hallo Michael,

wo kommen denn die Daten her?

Kommen aus einem web-stream, werden ausgelesen, angepasst und müssen gleich wieder weggeschrieben werden, weil sonst der Arbeitsspeicher darunter leidet.

Können die nicht im Worker erzeugt/verarbeitet werden?

Ist egal, ob ich das Problem des "Wegschreibens" im mainthread oder im worker thread habe. Und ich möchte den Stream ungerne anhalten. Es dauert jetzt schon ca. 110 Sekunden, es muss schneller werden.

Wieviele GB willst du denn an die Datenbank schicken? Evtl. ist der Datentransfer an den Worker ja garnicht so ein Problem.

Die einzelnen Datensätze sind nicht groß, es sind aber eben sehr viele, ca. 80.000 pro Einlesevorgang. Des Wegschreiben (zum späteren Einlesen bei Bedarf) kostet CPU-Zeit, ebenso eine Workerinstanz ist relativ zeitintensiv. Einen Worker würde ich eben nur nutzen wollen, wenn im main thread das Schreiben in eine IndexedDB nicht wirklich parallel ablaufen kann. Parallel bedeutet hier, die Datensätze in unterschiedliche Tabelle reinschreiben. Ich kann mir natürlich auch einen CPU-Monitor aufrufen und dort die Auslastung anschauen. Aber das muss doch auch irgendwo nachlesebar sein, ob die JS-Engige gewissen DInge selbst auf einen seperaten Thread auslagert.

Aber es müsste doch einen besseren Weg geben, um zu testen oder eine Suchmaschine zu befragen, ob eine async Aufgabe. Gerade im Zeitalter von Multicore CPUs ist es doch sinnvoll wenn möglichst alle CPU-Cores genutzt werden und schennler fertig ist.

Betriebssysteme haben so etwas wie eine Aktivitätsanzeige. Bei meinem Macbook geht die Anzeige auf fast 1000% hoch, es werden also 10 CPU-Kerne von 10 Workern gequält.

Die Aktivitätsanzeige zeigt auch die Speicherbelegung an.

Gruß
Jürgen

[Rolf B]

Hallo Michael,

wir wissen es nicht. Und wir nehmen auch nur gelegentlich Rechercheaufträge entgegen.

Was Du da tust, ist nicht Teil der JS Engine, sondern der Web-APIs des Browsers. Wie dieses API implementiert ist, kann sich von Browser zu Browser unterscheiden. Letzten Endes musst Du Dich auch fragen, ob der Browser das geeignete Tool für deine Aufgabe ist, wenn das Ergebnis zu lange braucht oder der Speicher aus den Fugen gerät.

Beachte auch, dass die Persistenz der IndexedDB nicht garantiert ist. Der Browser gesteht jeder Website eine gewisse Menge an Speicher zu und prüft auch, ob die Platte voll wird. Bei "Speicherüberdruck" kann er Daten aus IndexedDB, LocalStorage oder Cache löschen.

Du kannst aber über das Storage API Persistenz anfordern

Rolf