Going off on a tangent, I was curious how large the overhead of the
toObject() wrapping was when calling methods on primitive string
values. I used the following script, with the second line optionally
commented out:
var str = "The quick brown fox jumps over the lazy dog";
// comment this line out for implicit toObject() conversion
str = new String(str);
var start = Date.now();
for (var i = 0; i < 10000; i++) {
str.charAt(0);
str.charAt(1);
str.charAt(2);
str.charAt(3);
str.charAt(4);
str.charAt(5);
str.charAt(6);
str.charAt(7);
str.charAt(8);
str.charAt(9);
str.charAt(10);
str.charAt(11);
str.charAt(12);
str.charAt(13);
str.charAt(14);
str.charAt(15);
}
print(Date.now() - start);
With Rhino, the script runs around 25% faster with method invocation
on the string object compared to the string primitive value. That's
pretty reasonable IMO, it shows how cheap object creation/garbage
collection overhead is in modern JVMs, and that invoking the String
wrapper constructor in Rhino is quite fast.
What really surprised me was the behaviour with Spidermonkey and V8 -
both of them run faster when invoking methods on the primitive value
than the object wrapper! So it looks like these engines take some
shortcuts here to get from a string primitive to the String.prototype
methods. I just thought that was a noteworthy observation.
Hannes
On 12 Nov., 10:48, Marc Guillemot <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> as far as I know, it isn't explicitly documented anywhere how Rhino
> exposes JavaScript primitives.
>
> Current implementation exposes types as follows:
> JS String primitive -> java.lang.String
> JS Boolean primitive -> java.lang.Boolean
> JS Number primitive -> mostly as java.lang.Double but not consistently
> (see bughttps://bugzilla.mozilla.org/show_bug.cgi?id=367692)
>
> As described in bug #374918
> (https://bugzilla.mozilla.org/show_bug.cgi?id=374918), these java types
> are not appropriate to represent JS primitives correctly because they
> don't allow to store any information on the attached scope. This means
> that we have to use new classes, lets say for instance PrimitiveString,
> PrimitiveNumber and PrimitiveBoolean that hold both the value and the
> scope to fix the problem. This requires significant changes but this works.
>
> The problem with this PrimitiveXxxx change is that it is automatically
> visible to Java host objects, at least in following cases:
> - methods accepting an Object as parameter
> - methods accepting an Object[] as parameter
> in the other case it is probably possible to hide the details of the
> implementation and to get the java.lang.X from the PrimitiveX.
>
> Now my question:
>
> is it a change that can be imposed to Rhino users or has this design
> error to remain here for ever to avoid breaking existing code?
>
> Of course, I'd prefer the first way as I'd really like to see this bug
> fixed ;-)
>
> Cheers,
> Marc.
> --
> Web:http://www.efficient-webtesting.com
> Blog:http://mguillem.wordpress.com
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
