<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">OK, thanks, that answers my question!<div class=""><br class=""></div><div class="">[>] Brian</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 7:31 AM, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" class="">isiahmeadows@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">For what it's worth, engines already optimize for static object layouts. So if you never change the property set for instances of that class, the struct won't help performance much in practice. Similarly, standard arrays with just numbers are almost as fast as typed arrays as well, so unless you're in serious performance critical, likely asm.js, code, you might get a 0.5% boost. </p>
<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jun 20, 2016, 11:20 Brian Barnes <<a href="mailto:ggadwa@charter.net" class="">ggadwa@charter.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as I can read, Typed Objects/Structs are in consideration for a<br class="">
later version of ecmascript (but not in the spec) and there exists some<br class="">
implementations.  It depends on the engine, but has there been any<br class="">
thought to how costly they might be to fake at least some rudimentary<br class="">
type support?  For instance:<br class="">
<br class="">
class point2D<br class="">
{<br class="">
        constructor()<br class="">
        {<br class="">
                this.props=new Structure({<br class="">
                        x:uint32,<br class="">
                        y:unit32<br class="">
                });<br class="">
        }<br class="">
<br class="">
        setMe(x,y) {<br class="">
                this.props.x=x;<br class="">
                this.props.y=y;<br class="">
        }<br class="">
}<br class="">
<br class="">
This doubles the property lookups but that can probably be optimized<br class="">
away (maybe) -- but it does force the engine to consider x/y as always<br class="">
ints.  Of course, this doesn't do anything about the function signatures.<br class="">
<br class="">
I don't think types are coming anytime soon, and just wondering if, in<br class="">
the future, messy code like this might be worth it, or otherwise, to let<br class="">
implementers know this is something that people might try with their<br class="">
code and would be an interesting path to look at.<br class="">
<br class="">
[>] Brian<br class="">
_______________________________________________<br class="">
es-discuss mailing list<br class="">
<a href="mailto:es-discuss@mozilla.org" target="_blank" class="">es-discuss@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank" class="">https://mail.mozilla.org/listinfo/es-discuss</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>