Schleife < >

[Paul]

Moin.

Gibt es einen (Performance-)Unterschied zwischen folgendem:

1. for(var i; navCtrls.length > i; i++) ...

2. for(var i; i < navCtrls.length; i++) ...

Danke,
Paul

[Jens Holzkämper]

Tach,

Gibt es einen (Performance-)Unterschied zwischen folgendem:

1. for(var i; navCtrls.length > i; i++) ...

2. for(var i; i < navCtrls.length; i++) ...

unwahrscheinlich und wenn wäre der vielleicht sogar je nach Engine unterschiedlich. Über derartige Microoptimierung nachzudenken, lohnt sich frühestens, wenn man einen Use Case hat, wo es ein Problem verursacht. Wenn es das tut, dann hat man dann ja auch schon einen guten Testcase, um es einfach auszuprobieren.

mfg
Woodfighter

[dave]

Hi,

folgendes würde eine verbesserte Performance bringen:

for(var i, length = navCtrls.length; i < length; i++) …

Wie viel Performance hängt davon ab was navCtrls ist und wie weit unterhalb in der Prototype-Chain sich .length befindet.

~dave

[Jens Holzkämper]

Tach,

folgendes würde eine verbesserte Performance bringen:

for(var i, length = navCtrls.length; i < length; i++) …

Wie viel Performance hängt davon ab was navCtrls ist und wie weit unterhalb in der Prototype-Chain sich .length befindet.

und, ob die Javascript-Engine das nicht gleich selber optimiert (was nur ginge, wenn die Schleife als atomar betrachtet würde und keinen Einfluß auf die Länge von navCtrls hätte).

mfg
Woodfighter

[Paul]

Danke Euch!

[molily]

for(var i, length = navCtrls.length; i < length; i++) …

Wie viel Performance hängt davon ab was navCtrls ist und wie weit unterhalb in der Prototype-Chain sich .length befindet.

und, ob die Javascript-Engine das nicht gleich selber optimiert (was nur ginge, wenn die Schleife als atomar betrachtet würde und keinen Einfluß auf die Länge von navCtrls hätte).

Im Prinzip könnte der Compiler durch statische Code-Analyse klären, ob sich length ändern kann, aber ich denke nicht, dass er es tut, daher wird er es nicht automatisch optimieren. Wenn man navCtrls.length schreibt, dann wird das auch immer als solches ausgeführt: Ein Identifier wird aufgelöst und eine Referenz wird erzeugt, daran mit dem Property Accessor eine Eigenschaft geholt, welche ja auch ein Getter sein könnte. In ECMAScript 5 kann man diesen Vorgang nicht wegoptimieren.

Mathias

[Jens Holzkämper]

Tach,

Im Prinzip könnte der Compiler durch statische Code-Analyse klären, ob sich length ändern kann, aber ich denke nicht, dass er es tut, daher wird er es nicht automatisch optimieren. Wenn man navCtrls.length schreibt, dann wird das auch immer als solches ausgeführt: Ein Identifier wird aufgelöst und eine Referenz wird erzeugt, daran mit dem Property Accessor eine Eigenschaft geholt, welche ja auch ein Getter sein könnte. In ECMAScript 5 kann man diesen Vorgang nicht wegoptimieren.

danke, hatte gehofft, dass jemand auftaucht, der da tieferen Einblick hat als ich. Mit einem Java-Iterator wäre das nicht passiert ;-)

mfg
Woodfighter

[Gunnar Bittersmann]

@@dave:

nuqneH

folgendes würde eine verbesserte Performance bringen:
for(var i, length = navCtrls.length; i < length; i++) …

Noch mehr würde wohl eine Vorbelegung von i mit einem Startwert bringen. ;-)

Ich könnte mit auch vorstellen, dass Vergleiche gegen 0 minimal schneller sind als Vergleiche gegen einen anderen Wert. Also die Schleife – wenn es die Programmlogik erlaubt – rückwärts laufen lassen.

Qapla'