"no strict"; directive
andrea.giammarchi at gmail.com
Fri Nov 16 14:45:48 PST 2012
so dropping retrieve*Something*FromVMCode which I believe is one reason
methods with arguments/caller access cannot be optimized runtime properly
is not a performance/"use strict" goal ? So now I am confused ... gonna dig
there too ...
On Fri, Nov 16, 2012 at 2:36 PM, Oliver Hunt <oliver at apple.com> wrote:
> On Nov 16, 2012, at 2:11 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
> but I don't see caller being any better/worse than arguments and I believe
> arguments will stick around "forever" in any case ... so will caller,
> unless there's not some specific personal reason but the code just looks
> basically the same: find the rabbit and "ta-daaaaa"
> Yes, it would be silly to create today something based on an assumption
> such "future browsers optimizations will come after ES6" but on the
> practical level we all know it's going to be like that, right? Or even ES7
> ... thanks for your answer.
> Not understanding how features need to be/are implemented (or an
> unwillingness to investigate) isn't a good basis for making statements like
> What you seem to be (willfully) ignoring is that someFunction.caller
> requires a stack walk. That is what it is defined as doing.
> |arguments| is a magic _local_ variable - there is no stack walk involved,
> only the local call frame matters, there is no stack reconstruction
> necessary (in the sane use cases any way - insane use cases trigger
> dramatic costs, and someFunction.arguments has all the problems on
> someFunction.caller, with a few additional costs thrown in for good
> On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden <jwalden+es at mit.edu> wrote:
>> On 11/16/2012 01:42 PM, Andrea Giammarchi wrote:
>> > @Oliver, if you need to retrieve the caller in order to know if it's
>> strict or not, then everything I've read in this thread becomes kinda
>> pointless :-(
>> Not quite. You could imagine a system where you simply have to know if
>> your caller is strict or not. If it is, then you don't need to track any
>> of that info. If it isn't, then you'd need some system to compute the
>> caller. But it's certainly not the case that you always have to keep the
>> caller around regardless.
>> > It looks like there's no gain at all using strict and the goal here is
>> "simply" to get rid of these calls exec->interpreter
>> > ()->retrieve*something*FromVMCode(exec, thisObj);
>> Just to note, knowing that it's impossible to access the caller also
>> benefits inlining -- you don't have to be able to recompute the caller
>> function (or all the inlined function's stack modifications) at any moment
>> when you're in function code that's been inlined in a caller. I would
>> provide you a link to a blog post I wrote a year or so ago with more
>> details on this, but it's currently down. :-( Maybe I should spend the
>> time to bring it back up now so I can pass that link along.
>> > am I wrong? Can I ask when and if it's planned to get rid of this
>> isStrictMode() method? This, as info, would be definitively valuable ( FF
>> and Chrome guys welcome to answer to this as well, thanks )
>> I wouldn't speculate as to when any engine will take advantage of this --
>> SpiderMonkey that I work on, or any of the others. It's still somewhat
>> early in the JS optimization race, so it's likely there's more low-hanging
>> fruit to be picked in all the engines, that benefits all code and not just
>> strict mode code, before this would happen. As regards SpiderMonkey
>> particularly, I think we have enough things on our plates now that taking
>> advantage of this particular optimization opportunity won't happen in the
>> next year or so.
>> Taking advantage of this also has some interesting interactions with
>> other functionality like debuggers, Error.stack, error messages, and so on.
>> The simple thing, that's been done forever, is to just always track it.
>> But there's no reason not to specialize, and optimize harder, in the cases
>> where these complications can be worked around or set aside.
>> In the long run, however, something like this will happen. It would be
>> short-sighted to take on the semantic nightmare mid-stream strict mode
>> opt-out would present, simply because engines aren't immediately taking
>> advantage of all the optimization opportunities strict mode presents.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss