An Introduction to JS-Ctypes

[Brendan Eich]

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 <brendan at mozilla.com> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110918/b776ec9b/attachment.html>