On Sep 18, 2011, at 12:09 AM, Andrea Giammarchi wrote:
> at least now we agree object literals *add* overhead
Who ever said they didn't?
> and with current JS.next typed structs/arrays proposal you can bet developers
> will do those kind of non-sense things ;-)
I see what you are getting at now, but you're missing something: your test2 has
an object literal per loop iteration which cannot be optimized away easily. The
object and array literals in my slide that you are concerned about:
new Triangle([{ point: { x: 0, y: 0 },
color: { r: 255, g: 255, b: 255 } },
{ point: { x: 5, y: 5 },
color: { r: 128, g: 0, b: 0 } },
{ point: { x: 10, y: 0 },
color: { r: 0, g: 0, b: 128 } }]);
are neither mandatory -- see
http://wiki.ecmascript.org/doku.php?id=harmony:binary_data_semantics#array_objects
and note how you can call new Triangle() and set members using dotted access
and assignment -- nor as hard to optimize away than in the general case.
> I have updated the test case using a second Int32Array loop simply to access
> the index
How did the performance change?
/be
>
> On Sun, Sep 18, 2011 at 6:03 AM, Brendan Eich <[email protected]> wrote:
> On Sep 17, 2011, at 10:34 PM, Andrea Giammarchi wrote:
>
> > Brendan I wrote I did it on purpose trying to predict what JS devs will do
> > once JS.next will bring ctypes like syntax.
>
> My objection is that you're confounding test2 by adding object literal
> overhead to each loop iteration, in addition to typed array accesses. You
> want to focus on just the typed array accesses, from what I can tell of your
> benchmark.
>
> /be
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
