henso.com
Home
Archive
Search

rss feed for this page

DELI
HLM

LNGR
EURN
OON
CHLM
POOL
ELPH
RIST
SOFA
SENS
P3K
FM4
SCRP
MAL
RNS
GDNY
ELEG
OSNS
SLSH

Mozilla, baby!

antville.org
 Wednesday, 22. November 2006 

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.


 lehni , 22. November 2006 gegen 18:26 

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...

 hns , 22. November 2006 gegen 19:12 

> 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.

Log in to add your comment!

Not logged in. Click here to log in.

 comments