performance analyse

[00willson]

Hallo zusammen.

Ich suche ein Tool, daß mir bei der Analyse der Performance meines verwendeten JS hilft. Gibts da was erwähnenswertes? Bin zum Bsp. über "jsLex" gestolpert. Kennt das jemand? Kann man das empfehlen? Gibts Alternativen?

Der Hintergrund: ich bastel gerade an einer JS-lastigen Web-Applikation und möchte diese bestmöglich performant halten. Allerdings geht mir bspw. das FireBug-PlugIn "YSlow" nicht weit genug. Optimal wär ein Tool, daß den JS-Code analysiert und einen spezifischen und detailierten Report erstellt a la:
"Zeile 104: for(...) {} is langsam. Besser wäre hier do-while {}."

Besten Dank vorab!

[Struppi]

Ich suche ein Tool, daß mir bei der Analyse der Performance meines verwendeten JS hilft. Gibts da was erwähnenswertes? Bin zum Bsp. über "jsLex" gestolpert. Kennt das jemand? Kann man das empfehlen? Gibts Alternativen?

Nein ich kenne keines, aber ...

..., daß den JS-Code analysiert und einen spezifischen und detailierten Report erstellt a la:
"Zeile 104: for(...) {} is langsam. Besser wäre hier do-while {}."

Sowas gibt es sowieso nicht, ein Profiler sagt dir in welcher Funktion du am meisten Zeit verbrätst, aber das dürfte in JS alles nicht relevant sein. Die wirklich entscheidenen Unterschiede gibt es im DOM und da wird dir kein Profiler helfen sondern nur Erfahrung.

Ich hab z.b. einen Tabellensortierer an dem ich lange gefeilt habe, da er anfänglich bei vielen Zeilen sehr langsam, war. Ich habe dann irgendwann rausgefunden, das es am schnellsten ist die Tabelle zu clonen und dann anstatt der alten Tabelle neu in das Dokument einzuhängen. Im gegensatz dazu hatte ich in der ersten Version die Tabellenelemente an sich sortiert und innerhalb der Tabelle umgehängt, was wesntlich langsamer war.

Dann gibt es z.b. auf quirksmode.org einen Vergleich zwischen innerHTML und DOM, wo auch deutlich wird, wie gross die Unterschiede zwischen den Methoden sind.

Während es beim entfernen von Elementen wieder anders aussehen kann, wie dieser Versuch zeigt.

So einfach, wie du dir es vorstellst ist es also nicht. Zusätzlich hast du noch das Problem der Speicherlöcher im IE.

Also wirklich optimieren kannst du in JS nur mit Grips und Geduld.

Struppi.

[00willson]

Sowas gibt es sowieso nicht, ein Profiler sagt dir in welcher Funktion du am meisten Zeit verbrätst, aber das dürfte in JS alles nicht relevant sein. Die wirklich entscheidenen Unterschiede gibt es im DOM und da wird dir kein Profiler helfen sondern nur Erfahrung.

Ok. Schade.
Besten Dank zurück!

[Struppi]

Ok. Schade.
Besten Dank zurück!

Du kannst natürlich versuchen, ob dir ein Profiler hilft  (es gibt noch mehr JS Profiler, ich kann aber keinen empfehlen, da ich sowas noch nie benutzt habe)

Struppi.

[Kai345]

[latex]Mae  govannen![/latex]

Ich suche ein Tool, daß mir bei der Analyse der Performance meines verwendeten JS hilft. Gibts da was erwähnenswertes? Bin zum Bsp. über "jsLex" gestolpert. Kennt das jemand? Kann man das empfehlen? Gibts Alternativen?

Der Hintergrund: ich bastel gerade an einer JS-lastigen Web-Applikation und möchte diese bestmöglich performant halten. Allerdings geht mir bspw. das FireBug-PlugIn "YSlow" nicht weit genug. Optimal wär ein Tool, daß den JS-Code analysiert und einen spezifischen und detailierten Report erstellt a la:
"Zeile 104: for(...) {} is langsam. Besser wäre hier do-while {}."

Das sind Optimierungen im Micro-Bereich, die zwar in der Summe oder bei bestimmten Aktionen auch etwas bringen (siehe Struppi) [ja, ich optimiere Schleifen und so etwas auch machmal, gebe ich zu[1]] aber bei der Abarbeitungsgeschwindigkeit doch meist nicht wirklich _sehr_ viel (es sei denn, die Schleife iteriert im 5+ -stelligen Bereich [oder man verwendet IE ;) ] ) man sollte sich erst einmal um die Dinge kümmern, die den visuellen Aufbau wirklich beschleunigen:
Script ganz unten ins Dokument einhängen (schlägt ySlow ja auch vor) und vor allem nicht auf Bilder warten, das heißt statt window. onload bei modernen Browsern auf "DOMContentLoaded" reagieren. Das bringt _viel_ mehr als ein paar µs/ns in einer Schleife.

Cü,

Kai

[1] aber insbesondere bin ich im "Script darf auf keinen Fall einen Fehler werfen"-Wahn