Schon ein bisschen eine bombshell: wer bisher ein JS-Array in Rhino nimmt, es von 0..n bevölkert und dann irgendwelche Methoden darauf aufruft, der lässt möglicherweise einen Haufen Zeit in sinnlosen Loops liegen. Goes to show man darf nie davon ausgehen, dass "reife" Software auch wirklich durchoptimiert ist.

Also see: Wikipedia/Hash table#Open addressing vs. chaining.

Seltsam indeed!

Mir viel mal auf dass for-in viel längsämer ist als selber zählen im Loop, was ich ebenfalls seltsam fand, da ein Loop ja native viel effizienter umgesetzt werden könnte. Hier ist das Problem, dass for-in einen Array aller Property Ids per getIds() hohlt, und dann durch die iteriert. d.h. es wird für ein Array mit n Einträgen für jeden Loop ein zweiter Array mit n Einträgen erstellt, alles andere als optimal...

Eine Lösung wäre, ein Enumeration Interface für Rhino zu implementieren, wie hier vorgeschlagen.

Leider ist die Diskussion dort mit einer anderen vermischt, die was mit BeanProperties zu tun hat, im typischen lehni-scatterbrain-way of doing things ;)

Ich finde nach wie vor dass das Sinn machen würde und in einer Weise umgesetzt werden könnte, die das API nach aussen nicht verändert. getIds() könnte ja dann den Iterator verwenden, um durch die Ids zu iterieren und die in einem Array zu sammeln. Das ganze könnte mit einem Interface eingebaut werden, und falls eine Klasse das nicht implementiert, wär das Fallbackszenario halt immer noch, per getIds einen Iterator zu erstellen für den Loop...

Ich bin überzeugt dass es noch viele solche Möglichkeiten zu weiteren Optimierungen gibt...

> dass for-in einen Array aller Property Ids per getIds() hohlt, und dann durch die iteriert

zwei arrays: eines, weil wir nicht genau wissen, wieviele enumerable props wir haben, das zweite, um das erste zurechtzuschneiden.

prinzipiell ist rhino schon ziemlich gut durchoptimiert. glaub ich.

Not logged in. Click here to log in.