On Sep 18, 2011, at 11:12 PM, Andrea Giammarchi wrote:
right, that's nice, just wonder if at that time to pass an object will be
slightly ambiguous
function fn({a: a = {}, b: b = true}) { ... }
fn(genericObject) will fail as first argument so that
No, that would not fail. There is no
right, that's nice, just wonder if at that time to pass an object will be
slightly ambiguous
function fn({a: a = {}, b: b = true}) { ... }
fn(genericObject) will fail as first argument so that
fn({a: genericObject}) will be necessary
If these things are optimized on engine levels then who
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.com wrote:
The point is that you don't *have* to pass a fresh object literal to each
constructor call.
/be
I know Brendan, my point is that I can predict devs will do every time
we'll see
Thanks for other reply, I thought
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.com wrote:
The point is that you don't *have* to pass a fresh object literal to each
constructor call.
/be
I know Brendan, my point is that I can predict devs will do
I know it's the same, for this reason I said it was shimmable
New syntax would be fine as long as minifiers won't break everything so ...
as long as minifiers are compatible, but this is an extra story I guess,
also it's not fundamental it's just nicer addiction since many libs are
using single
On Sep 18, 2011, at 12:09 PM, Andrea Giammarchi wrote:
I know it's the same, for this reason I said it was shimmable
New syntax would be fine as long as minifiers won't break everything so ...
as long as minifiers are compatible, but this is an extra story I guess, also
it's not
my thoughts, my benchmark, and my worries about JS.next StructType and
ArrayType:
http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
I know current Mozilla implementation is not exactly what will be in JS.next
but it was the only way I had to test efficiency of this proposal
@mozilla.org
Subject: An Introduction to JS-Ctypes
my thoughts, my benchmark, and my worries about JS.next StructType and
ArrayType:
http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
I know current Mozilla implementation is not exactly what will be in JS.next
On Sat, Sep 17, 2011 at 4:12 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
my thoughts, my benchmark, and my worries about JS.next StructType and
ArrayType:
http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
This blog post is confusing 3 different things, and
Andrea;
On 17 September 2011 04:12, Andrea Giammarchi
andrea.giammar...@gmail.comwrote:
I know current Mozilla implementation is not exactly what will be in
JS.next but it was the only way I had to test efficiency of this proposal
and performances speaking it looks like an epic fail so far
First of all thanks for clarifications ... as I have said, js-ctypes
extension looked way too similar to what Brendan showed in his slides.
In any case, there are still a couple of confusing points to me and yes, I
will update my post as soon as these things are clear.
For example ...
1.
On Sep 17, 2011, at 2:34 PM, Andrea Giammarchi wrote:
Also I have explicitly slowed down the logic creating a classic literal JS
object per each loop iteration ... still, way too slow performances so
whatever js-ctypes has been created for, something went wrong, imo
Why are you doing that?
On Sat, Sep 17, 2011 at 2:34 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
First of all thanks for clarifications ... as I have said, js-ctypes
extension looked way too similar to what Brendan showed in his slides.
In any case, there are still a couple of confusing points to me and
On Sep 17, 2011, at 2:54 PM, Sam Tobin-Hochstadt wrote:
There's an excellent overview of how to write
high-performance JavaScript code by David Mandelin here:
http://blog.mozilla.com/dmandelin/2011/06/16/know-your-engines-at-oreilly-velocity-2011/
this has been linked in the post itself
On Sep 17, 2011, at 3:02 PM, Brendan Eich wrote:
An exception, or special case if you will: using Function or eval up front,
hoisted and common'ed out of loops, and (this is crucial
for eval, I meant to write here.
) not called from a function that you want optimized, in order to generate
Brendan I wrote I did it on purpose trying to predict what JS devs will do
once JS.next will bring ctypes like syntax.
I wrote the object with properties only assigned too indeed but as is for
functions expressions usually created everywhere by common developers rather
than reused where possible
Can we at least agree that if some extension brings *exactly* same
constructor name, StructType and ArrayType, and more or less exactly the
same signature/usage of what Brendan showed in his slides it become kinda
natural to compare/test/confuse these two different implementations for
different
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
On Sep 17, 2011, at 10:39 PM, Andrea Giammarchi wrote:
Can we at least agree that if some extension brings *exactly* same
constructor name, StructType and ArrayType, and more or less exactly the same
signature/usage of what Brendan showed in his slides it become kinda natural
to
On Sep 17, 2011, at 10:48 PM, Andrea Giammarchi wrote:
So here I don't understand why Sam had to bring it into the discussion ...
anyway, still missing the answer from you Brendan:
Why JS.next is bringing StructType and requires an object description per
each created instance ?
Binary
at least now we agree object literals *add* overhead and with current
JS.next typed structs/arrays proposal you can bet developers will do those
kind of non-sense things ;-)
I have updated the test case using a second Int32Array loop simply to access
the index
On Sun, Sep 18, 2011 at 6:03 AM,
Cython is used to create Python extension so does js-ctypes ...
Cython is a superset of Python statically compilable so is, or it should be,
js-ctypes and/or JS.next proposal
The fact js-ctypes are not trace-JITed at all was *in any case* unexpected
to me and the fact js-ctypes are coupled with
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
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich bren...@mozilla.com wrote:
Binary data does no such thing! The descriptors are per generated
type-constructor, not per instance.
once you define a StructType how do create an instance ?
new Point2D({x: 0, y: 0});
or binary data can create
On Sun, Sep 18, 2011 at 6:19 AM, Brendan Eich bren...@mozilla.com wrote:
Who ever said they didn't?
Sam did:
You'd need a benchmark that shows that the object allocation you're
avoiding here is worth the lack of flexibility.
I see what you are getting at now, but you're missing something:
On Sep 18, 2011, at 12:22 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich bren...@mozilla.com wrote:
Binary data does no such thing! The descriptors are per generated
type-constructor, not per instance.
once you define a StructType how do create an instance ?
On Sep 18, 2011, at 12:34 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 6:19 AM, Brendan Eich bren...@mozilla.com wrote:
Who ever said they didn't?
Sam did:
You'd need a benchmark that shows that the object allocation you're
avoiding here is worth the lack of flexibility.
Sam
On Sep 18, 2011, at 1:14 AM, Brendan Eich wrote:
On Sep 18, 2011, at 12:22 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich bren...@mozilla.com wrote:
Binary data does no such thing! The descriptors are per generated
type-constructor, not per instance.
once
28 matches
Mail list logo
