Subj : Re: Fwd: Rhino, Changes to JavaMembers.java To : netscape.public.mozilla.jseng From : Igor Bukanov Date : Thu Feb 17 2005 04:34 pm Jürg Lehni wrote: > On 2005-02-16 10:39:01 +0100, Igor Bukanov said: > >> You can either send the patch to the newsgroup (I cross-post the mail >> there) or file an enhancement bug at bugzilla.mozilla.org against >> Rhino. And please use patches, not the files itself, as it is easier >> to see what happens. > > > Ok, so should I submit again, as a patch? For a change like that it is better to file a bugzilla.mozilla.org and attach path (in unified format) there. > And what do you think of the > proposed changes? It is a reasonable proposal. > >> The problem is that any optimization-only changes to Scriptable >> interface or any other public API in Rhino are hard to justify as it >> would break too many existing embeddings. To demonstrate how bad the >> situation could be consider the change in the debug implementation >> internals that was done in Rhino 1.5R4 in 2002. That change made Rhino >> incompatible with BSF library which explicitly depended on the >> modified classes. Since BSF is used in many projects from apache.org >> and since the last public release of the library was at the end of >> 2002, many people are still forced to use 1.5R3 release of Rhino. > > > I see. But as getIds() would be kept, I cannot see how this would break > anything at all. I don't know how big the speed gain would be, but to me > it seems a bit crazy to create an array containing all indexes of the > array to be enumerated just to walk through its elements. While i really > like the "for (i in array)" syntax, the fact that Rhino handles it in > that way makes it very slow compared to "for (var i = 0; i < > array.length; i++)" for huge arrays... Do you have any benchmarks that shows that for (var i = 0; i < array.length; i++) is faster for a huge array? >I just thought that would be an > easy to implement modification that wouldn't really harm any project > depending on this. It could be done by creating a new interface called > 'enumeratable', and if the class implements this, the new mechanism is > used. If it's not there, the fallback scenario is using getIds() just > like it was done until now. It would not work like that since getIds is used by external applications. So you would need to implement getIds in terms of the new interface as well. So it is a lot of code just to optimize not that often used construction. Plus again, do you really think it would optimize the enumeration by any noticeable margin? Regards, Igor .