Andrea; On 17 September 2011 04:12, Andrea Giammarchi <[email protected]>wrote:
> 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 and please feel > free to correct me as much as possible, thanks. > > I ... just don't know where to begin. JS-CTypes is a foreign-function interface for SpiderMonkey. It's purpose is to allow JavaScript programs to execute code in native C libraries. It was developed so that extension developers could call into native libraries without shipping binary extensions, thus improving extension compatibility from one version of the browser to another. In order to know how to pass arguments to C functions, you need to know the data types, so some special JS Objects were created to host the data and carry type information with them. I don't understand why you expect these special-purpose JS objects to be faster than JS values at storing numbers. Of course they are going to be slower. Similarly, I don't understand why you would compare JS-CTypes with Cython. A much better analogue is Python's CTypes. > "*check all properties, check all types, convert them into C compatible > structs, bring them back to JS world per each index access*" ... I mean, > this cannot be the way to make things faster. Of course not, don't be ridiculous. It is not the way to make JS faster. It is the way to make JS interoperate with C libraries. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
