Hi Robert,

> I read somewhere the other day that
>
> y=Math.pow()
>
> is much faster than
>
> x=Math.pow
> y=x()
>
> because v8 can make a direct lookup of the symbol.

You probably read it in my post "Performance tuning as the art of
weather forecast"[1].

However it has nothing to do with "direct lookup of the symbol", but
rather with whether optimizing compiler recognizes that the code is
calling built-in pow and handles it in a very special way or not. To
quote the post itself:

    This happens because V8’s optimizing compiler has two separate methods
    to perform inlining of recognized built-ins:
TryInlineBuiltinMethodCall handles
    inlining at method invocation o.m() and
TryInlineBuiltinFunctionCall that handles
    inlining at free function invocation f().

    Right now Math.pow is handled only in TryInlineBuiltinMethodCall so it
    is not recognized or even inlined when it is called as a free
    function.

This doesn't affect normal JavaScript functions in any way so you
should not be worried.

Also new optimizer pipeline for V8 called TurboFan doesn't make this
mistake - it has a single function that handles inlining of
builtins[2] so eventually when TurboFan is enabled this strange
performance issue for pow will go away.

Though of course before that JSBuiltinReducer will have to learn how
to reduce a lot more different builtins than it knows now.

[1] http://mrale.ph/blog/2013/04/29/performance-tuning-as-weather-forecast.html
[2] 
https://github.com/v8/v8/blob/6faa6b317ab029c8379eda520a3ba6d28bbd5258/src/compiler/js-builtin-reducer.cc#L145-L170
Vyacheslav Egorov


On Mon, Jan 18, 2016 at 4:52 AM, Benedikt Meurer <[email protected]> wrote:
> Hey Robert,
>
> It depends on the context: if your x is a property of the global object,
> then V8 still optimizes Math.pow in your example. Even if it's a local
> variable, we might still be able to optimize this in many cases.
>
> But to answer your question: The polyfill assignment won't break the
> optimizations.
>
> HTH,
> Benedikt
>
>
> <[email protected]> schrieb am Mo., 18. Jan. 2016, 00:30:
>>
>> Hi v8-dev,
>>
>> I read somewhere the other day that
>>
>> y=Math.pow()
>>
>> is much faster than
>>
>> x=Math.pow
>> y=x()
>>
>> because v8 can make a direct lookup of the symbol. I now wonder what
>> happens with polyfills of newly arrived functions like Math.cosh:
>>
>> Math.cosh = Math.cosh || function(x) {
>>     return (Math.exp(x) + Math.exp(-x)) / 2;
>> };
>>
>> Is a polyfill breaking the optimization because the function was maybe
>> labeled as changed or did you consider this somehow?
>>
>> Thanks Robert
>>
>> --
>> --
>> v8-dev mailing list
>> [email protected]
>> http://groups.google.com/group/v8-dev
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> v8-dev mailing list
> [email protected]
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to