Subj : Re: Fwd: Rhino, Changes to JavaMembers.java To : netscape.public.mozilla.jseng From : =?ISO-8859-1?Q?J=FCrg_Lehni?= Date : Thu Feb 17 2005 06:27 pm On 2005-02-17 16:34:42 +0100, Igor Bukanov said: > 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. Ok, I've submited it now: https://bugzilla.mozilla.org/show_bug.cgi?id=282595 >> 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? Not really. It's just a guess that it does not really make sense to create one array of the same length to just walk through another array. And it's not really a nice design. Iterators would have made much more sense there. > >> 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? Yes, but getIds would still be there. Maybe there's a base class instead of an interface that defines the getIds that relies on the iterator. I think the optimization should be quite noticable, especially memory wise, for bigger arrays... Jürg .