JavaScript parser animation
MB
1 dedlfix
0 MB
1 
Der Martin
0 MB
4 
Rolf b
0 Der Martin
0 MB
JavaScript parser animation
MB
Moin!
ich möchte gerne wissen...
- ...ob der Parser javascript für animationen einließt und in bytecode umwandelt, sodas er den Sourcecode nicht mehr benötigt um zu animieren
- ...oder muss er alle naslang den sourcecode neu interpretieren?
Schöne Nacht und Guten morgenn,
MBLG
PS.: Ich weis das man um animationen zu wirken CSS 3 verwendet. Rein aus neugier und interesse.
-
Tach!
- ...ob der Parser javascript für animationen einließt und in bytecode umwandelt, sodas er den Sourcecode nicht mehr benötigt um zu animieren
- ...oder muss er alle naslang den sourcecode neu interpretieren?
Ein Parser hat nur die Aufgabe, Quellcode zu analysieren und in seine Bestandteile zu zerlegen. Kompilieren und Ausführen gehören nicht zu seinem Aufgabengebiet.
Wie eine Javascript-Engine intern arbeitet, ist Sache der konkreten Engine. Die Frage kann man nicht allgemein beantworten und eine mögliche Antwort auf einen konkreten Fall wäre auch nicht allgemeingültig. Die Beantwortung der Frage bringt dich nicht weiter, an den Gegebenheiten kannst du nichts ändern. Wenn dir etwas zu lange dauert, dann musst du dafür eine konkrete Lösung suchen, und du musst das für jede Engine / jeden Browser getrennt untersuchen. Und für den nächsten Fall musst du möglicherweise wieder von vorn anfangen.
dedlfix.
-
Ein Parser hat nur die Aufgabe, Quellcode zu analysieren und in seine Bestandteile zu zerlegen. Kompilieren und Ausführen gehören nicht zu seinem Aufgabengebiet.
Nicht gewusst, danke.
Wie eine Javascript-Engine intern arbeitet, ist Sache der konkreten Engine. Die Frage kann man nicht allgemein beantworten und eine mögliche Antwort auf einen konkreten Fall wäre auch nicht allgemeingültig.
Das habe ich leider vermutet
Danke für die AW
VLG MB
-
Hallo,
ich möchte gerne wissen...
- ...ob der Parser javascript für animationen einließt und in bytecode umwandelt, sodas er den Sourcecode nicht mehr benötigt um zu animieren
- ...oder muss er alle naslang den sourcecode neu interpretieren?
man kann wohl davon ausgehen, dass die meisten Javascript-Engines den Code beim Parsen in eine interne Darstellung umwandeln, die dann performanter zu verarbeiten ist als der Quellcode selbst. Und das gilt natürlich nicht nur für Animationen, sondern für die Verwendung von Javascript generell.
Ob man das als "Bytecode" bezeichnen mag ... okay, warum nicht.Das ist aber nur eine Vermutung, basierend auf dem Wissen, dass manche Javascript-Engines so vorgehen. Und wie dedlfix schon audführte: Ob du das nun weißt oder nicht, nützt dir nicht wirklich.
PS.: Ich weis das man um animationen zu wirken CSS 3 verwendet. Rein aus neugier und interesse.
Kommt auf die Art der Animation an. Alles kann CSS auch nicht, und JS ist sicher flexibler.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy-
Moin Martin,
man kann wohl davon ausgehen, dass die meisten Javascript-Engines den Code beim Parsen in eine interne Darstellung umwandeln, die dann performanter zu verarbeiten ist als der Quellcode selbst.
verstehe.
PS.: Ich weis das man um animationen zu wirken CSS 3 verwendet. Rein aus neugier und interesse.
Kommt auf die Art der Animation an. Alles kann CSS auch nicht, und JS ist sicher flexibler.
Ganz genau. Aber gut das du es nochmal bestätigt hast
vgl mb
-
Es wird wohl keine JavaScript Engine geben, die den Quelltext ständig neu interpretiert. So dumm wäre ja nicht mal ich.
Es wird immer so sein, dass Syntaxprüfung und Umwandlung in ein Format, das man "nur noch" ausführen muss, beim Laden stattfinden. Das resultierende Format ist dann sehr verschieden, und bereits auf dieser Stufe sind unterschiedliche Grade von Optimierung möglich.
Es gibt auch JavaScript Engines, die nativen Maschinencode erzeugen. Wobei das auch nicht UNBEDINGT performanter sein muss. Man kann auch Maschinencode erzeugen, der aus einem Bibliotheksaufruf nach dem anderen besteht (Auabeispiel: IBM PC BASIC Compiler aus den 80ern: Reserviert die ganze Soft-Interrupt Tabelle für sich und macht aus jedem Befehl einen Interrupt-Aufruf). Viele Pseudocode-Interpreter laufen aber auf das gleiche Vorgehen heraus: Lies Pseudocode-Byte, hole Bibliotheksadresse dazu aus Tabelle, CALL, lies Pseudocodebyte, etc. Das KANN gelegentlich sehr fix sein und kompakten Code erzeugen (Clipper Compiler für dBase, 90er Jahre).
Der Unterschied in der Performance entsteht im Ausführungsmodell. Viele Pseudocode-Engines verfolgen ein Stackmodell: Sie schieben alle Arbeitsdaten auf einen Stack und rufen dann Bibliotheksfunktionen auf, die auf der Stackspitze operieren. (Push 3, Push 5, Add -> nimmt die 5 vom Stack und ersetzt die 3 durch eine 8). Wer mal einen HP Taschenrechner mit UPN hatte, kennt das :). Dabei finden viele Speicher-zu-Speicher Transfers statt. Ein guter JIT (just-in-time Compiler) ist im Stande, diese Stackoperationen in Registeroperationen passend zur Architektur des Prozessors zu übersetzen, und ggf. zu erkennen, dass ein Wert nur temporär ist, gleich wiederverwendet wird und daher im Register bleiben kann ohne im Speicher geparkt werden zu müssen. Schlaurere JIT sortieren auch deine Anweisungen um, wenn das Ergebnis logisch gleich bleibt und dadurch die Registerausnutzung besser ist oder die internen Abhängigkeiten im Prozessor besser koordiniert werden. Natürlich - je schlauer der JIT, desto länger muss er grübeln und desto länger braucht es, bis dein Programm anfängt, etwas zu tun. Es ist immer ein Balanceakt. Auf deinem Handy wirst Du eher einen dummen JIT finden, in Umgebungen wie node.js wird ein besserer JIT sitzen weil diese Umgebungen für länger laufende Scripte ausgelegt sind.
JavaScript ist ein relativ schwieriger Optimierungskunde, weil jedes Objekt in JavaScript eine Key-Value Map ist, die dynamisch modifiziert werden kann und nur die Spitze eines Eisbergs (sprich: Prototype-Chain) ist. Bei jedem Zugriff auf ein Property muss neu geprüft werden, wo das Property denn nun tatsächlich steckt. Und bei jedem Zugriff auf eine nicht-lokale Variable muss die gerade gültige Scope-Chain abgegrast werden. Die Optimierung dieser Zugriffe ist zentral für JavaScript, da ist ein JIT der nativen Maschinencode ausspuckt weniger wichtig. Diese Aufgabe löst jede JS Engine anders und unterschiedlich gut.
Rolf
-
Hallo Rolf,
klasse Beitrag, finde ich!
Du gehst zwar nicht unbedingt in die Tiefe (ist hier auch gar nicht gefragt), reißt aber eine Menge wesentlicher Aspekte an und regst den Leser an, selbst weiterzudenken.
Aber das Tag klugscheißerei hätte ich mir an deiner Stelle nicht angeheftet. Das klingt so negativ.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy -
nabed Rolf,
wow, sehr gut erklärt, Danke. Und sehr viele Fachbegriffe. Das weckt natürlich meine neugier. Nur grober Abriss: Wa sind die Begriffe die u nicht erklärt hasst? Ich kenne JIT nur am rande. Mich interessieren andere Begriffe die du genannt hast.
JavaScript ist ein relativ schwieriger Optimierungskunde, weil jedes Objekt in JavaScript eine Key-Value Map ist, die dynamisch modifiziert werden kann und nur die Spitze eines Eisbergs (sprich: Prototype-Chain) ist.
Was ist Key-Value Map, Prototype-Chain, Scope-Cain? Ich kenne aber den Begriff Prototyp in JavaScript und allgemein Scope in OOP.
vlg MB
-
-