"Not optimized" JavaScript profiler bailout reasons about devtools-docs HOT 43 OPEN

"Not optimized: Bad value context for arguments value"

Example: ?

Possible fix: ?

from devtools-docs.

"Not optimized: Optimized too many times"

V8 optimized this function, but while running it found a reason to deopt it. It tried later, reoptimized but then deopted again. This pattern happened repeatedly. It (re)optimized the function kMaxOptCount times, but on the kMaxOptCount + 1th time, it gave up trying to optimize.

Currently the max optimization count is set to 10.
(See max_opt_count in the v8 source)

Investigation

The challenge is that when V8 gave up after 10 times, it lost the original reason(s) why the function was deoptimized. We want to know that particular reason. (It could be any of the above-listed reasons (there are ~50 reasons in total.))

1. This only happens in functions that run > 10 times. So... (and this is a big of a hack), if the function runs less than 10 times, you should be able to get the reason. You can set a counter, increment it on each run, and when it hits 9, return early. Profiling that session should now provide the original reason on the deopt marker.
2. As @mraleph indicated above, you can also use IRHydra to find the deoptimized reason:
   

from devtools-docs.

"Not optimized: Unsupported phi use of const or let variable"?

from devtools-docs.

"Not optimized: Bad value context for arguments value"

Example:

function f1() {
  return arguments;
}

function f2() {
  var args = [].slice.call(arguments);
}

function f3() {
    arguments = 3;
    return arguments;
}

Possible fix:

function f3(fn) {
  var args = new Array(arguments.length);
  for (var i = 0, l = arguments.length; i < l; i++) {
    args[i] = arguments[i];
  }
  return fn.apply(this, args);
}

Updated per @WebReflection's comment.

from devtools-docs.

"Not optimized: Optimized too many times"

Example: ?

Possible fix: ?

kOptimizedTooManyTimes

from devtools-docs.

then in f3 case you should have full speed without needing to recreate the args to apply as described in this thread: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#what-is-safe-arguments-usage

the STRICTLY .apply part in special

from devtools-docs.

When talking about optimizations it's more polymorphism of each individual operation inside the function is more relevant than polymorphism of the function (that's why my blog post always talks about operations, call sites - not functions).

optimized too many times means only one thing - precisely what it says: V8 (re)optimized this function many times and eventually gave up.

In reality this very often actually means a bug in V8 - there is some optimization which is too optimistic so the generated code deopts all the time.

Just use IRHydra and look at the deoptimization reasons - the picture should become clear immediately.

Megamorphism of some operation is not the reason to not optimize the function - you can just emit an IC call there instead of specializing the operation.

from devtools-docs.

Found a stranger simpler example of "Bad value context for arguments value"

function formattedText(string, var_args) {
    var r = string
    for (var i = 1; i < arguments.length; i++) {
        r = arguments[i](r)
    }

    return r
}

function run() {
    document.body.innerHTML = formattedText(Date.now())
    setTimeout(run, 0)
}

run()

Let the profiler run this a couple of times and formattedText will be de-optimaized.

Without locally slice the arguments into an array but simply changing the body of the loop to:

var fn = arguments[i]
r = fn(r)

seems to fix it, curiosly closure compiler will rewrite it like:

r = (0, arguments[i])(r)

then oddly enough uglify will rewrite closure output as the initial de-optimized funciton...

Is the initial use of arguments unoptimizable?

from devtools-docs.

I came across the same "Not optimized: Unsupported phi use of const or let variable" bug as @spite and unsure of why exactly. Opened a pr here vhf/v8-bailout-reasons#10 with details.

from devtools-docs.

Want this as well; chiming in for updates.

from devtools-docs.

"Not optimized: Inlining bailed out"

Example

var obj = { prop1: ..., prop2: ... };

function f(obj) {
  obj.someOtherProp = ...;
}
f(obj);

or:

function someMethodThatAssignsSomeOtherProp(obj) {
  obj.someOtherProp = ...;
}
function f(obj) {
  someMethodThatAssignsSomeOtherProp(obj);
}
f(obj);

Possible fix

var obj = { prop1: ..., prop2: ..., someOtherProp: ... };
f(obj);

More on hidden classes.

from devtools-docs.

What: "Not optimized: ForInStatement is not fast case"

Example

for (var prop in obj) {
  /* lots of code */
}

Possible fix

function f() {
  /* lots of code */
}
for (var prop in obj) {
  f();
}

from devtools-docs.

(just pasting some notes; perhaps will come in useful)

from devtools-docs.

very useful. thank you sir.

from devtools-docs.

"Not optimized: Reference to a variable which requires dynamic lookup"

We bailout during optimization when there are variables for which lookup at compile time fails, and we need to resort to dynamic lookup at runtime.

Example

function f() {
  with ({x:1}) {
    return x;
  }
}

possible fix: refactor to remove the dependency on runtime-information to resolve the lookup.

mailing list thread with more discussion: https://groups.google.com/forum/#!msg/google-chrome-developer-tools/Y0J2XQ9iiqU/H60qqZNlQa8J

General bailout reason explanation.

V8 will not try to optimize functions with some constructs, try/catch block is one example, the full list may change over time as the engine evolves. It can also give up if it tries to optimize and then has to deoptimize some hot function too many times (e.g. because of the type feedback being different each time the function executes). Also you should pass --trace-opt flag in addition to --trace-deopt to see bailout reason when V8 fails to optimize a function.

see link for more

from devtools-docs.

"Not optimized: assignment to parameter in arguments object"

This is likely either of:

(function() {
  arguments[0] = ...;
})();

// or

(function(foo, bar) {
  foo = ...
})();

from devtools-docs.

I posed the question on SO - http://stackoverflow.com/questions/22509262/what-do-the-not-optimized-warnings-in-the-chrome-profiler-mean

from devtools-docs.

@twokul the first parameter for .apply is the context, not the arguments neither an array … I think you are passing arguments as context instead.

from devtools-docs.

Also, I think "Not optimized: Inlining bailed out" might be caused by a completely different bailout. Fox example, the function won't be inlined if the function that is called inside bails out. Cascading bailout?

from devtools-docs.

@WebReflection good catch!

from devtools-docs.

I have also the problem about the
'Not optimized: Optimized too many times'
that would be great to have reason or some hints when the compiler reject those optimization

from devtools-docs.

We've landed a bunch of patches recently to expose deopt reasons:
https://code.google.com/p/chromium/issues/detail?id=452067#c19
It's not done yet, but I'll ping this thread when there's something to try out.

from devtools-docs.

I can't make sense of the "Not optimized: Inlining bailed out" examples. A function f is defined that adds a property to an obj, and is then called with no args? So it throws on "cannot set property of undefined"? Fix is to.. what? Not define the function and then call it, so it throws on "undefined is not a function"? The example is extremely unclear.

from devtools-docs.

@acthp you're right, I made a mistake in my example (mind you, this is simply my assumption about the error — I haven't worked on a profiler, I don't know the actual meaning behind these messages). Updated/fixed example. The point is not to modify object at runtime. So instead of assigning property dynamically, a property would be created initially as part of an object literal. Of course this might not always be possibly but... that's besides the point.

from devtools-docs.

Hm... if that's the case, I wonder if initializing the property to undefined would help.

from devtools-docs.

"Not optimized:Yield"

The yield keyword is used in the function body.

from devtools-docs.

IMO "optimized too many times" means that function was optimized multiple times with wrong assumptions (both args are int! first is string the other is int? both are string?! I give up...). Check if types and order of params you pass to that function is always the same.

from devtools-docs.

@kdzwinel so you are saying a script language shouldn't have overloads like most common strict languages? wouldn't that be somehow hilarious :-) I'd rather like to know the eventual maximum amount of overloads can be optimized before "giving up", there are already so many native methods and functions in JS that accepts different amount of parameters with different kind of types, I don't think developers should avoid creating nice APIs because of this. just my 2 cents

from devtools-docs.

Knowing which variables aren't type-stable is useful for optimizing heavily-used inner loops. When performance doesn't really matter, you're probably not even looking at that function in the profiler in the first place.

from devtools-docs.

@WebReflection you sure can have polymorphic functions, they won't be as optimized an monomorphic ones. Which, in most cases, is OK.

After reading this article my guess is that "optimized too many times" warning is emitted not when V8 figures out that function is polymorphic, but when it figures out that it's megamorphic (see this summary).

If you need a definite answer, I suggest asking @mraleph.

from devtools-docs.

@mraleph thanks for an explanation! Now it makes much more sense, hopefully we will get that documented.

Since "optimized too many times" suggests a V8 bug, should we consider reporting it when we run into this warning? If so, should it be reported to https://code.google.com/p/v8/ or crbug.com ?

from devtools-docs.

@kdzwinel "Often" does not mean "always". I recommend actually investigating what happens, confirming that it looks like a bug and then filing a bug (with a repro) at V8's bugtracker.

from devtools-docs.

"Not optimized: Bad value context for arguments value"

Full writeup: https://gist.github.com/Hypercubed/89808f3051101a1a97f3

Adding a property to one function, but not all functions, causes Not optimized flag on function containing Function.prototype.apply.

Cause

"V8 only recognizes monomorphic .apply call-sites" - @mraleph

Example

var assert = require('assert');

// the following line causes "failed to optimize dispatch: Bad value context for arguments value" notification
dispatchOne.$ = 'Causes Bad value context for arguments value';

// the following line, if uncommented, will allow optimization
//dispatchTwo.$ = 'Allows optimization';

var callbacks = [dispatchOne, dispatchTwo];

for(var i=0;i<200000; i++) {
  dispatch(1,2,3,4,5);
}

function dispatch() {
  var i = callbacks.length;
  while (i--) {
    var cb = callbacks[i];
    cb.apply(null, arguments);
  }
}

function dispatchOne() {
  assert(arguments.length == 5);
}

function dispatchTwo() {
  assert(arguments.length == 5);
}

Fixes

• Don't attach properties to functions
• Copy arguments to an array. See twokul's comment above: #53 (comment)
• Provide a monomorphic .apply call-site (see below or fix.js)

Potential fix

function dispatch() {
  var i = callbacks.length;
  while (i--) {
    var cb = callbacks[i].bind(null);  // ensures "monomorphic .apply call-sites"
    cb.apply(null, arguments);
  }
}

Edit: Fix may be worse than the Not Optimized function.

from devtools-docs.

To add to my last comment the following also causes "Not optimized" flag on the dispatch function:

var assert = require('assert');

var callbacks = [dispatchOne, dispatchTwo.bind(0)];

for(var i=0;i<200000; i++) {
  dispatch(1,2,3,4,5);
}

function dispatch() {
  var i = callbacks.length;
  while (i--) {
    callbacks[i].apply(null, arguments);
  }
}

function dispatchOne() {
  assert(arguments.length == 5);
}

function dispatchTwo() {
  assert(arguments.length > 4);
}

from devtools-docs.

As a heads up, this github issue is now linked from the devtools:

from devtools-docs.

Not optimized: TryCatchStatement

Cause having a try catch statement within a function block.

from devtools-docs.

@spite I don't have an explanation yet but I added a rather minimal reproduction. (And here is a test on various recent node versions.)

from devtools-docs.

@spite here is the code responsible for throwing this warning

bool HGraph::CheckConstPhiUses() {
  int block_count = blocks_.length();
  for (int i = 0; i < block_count; ++i) {
    for (int j = 0; j < blocks_[i]->phis()->length(); ++j) {
      HPhi* phi = blocks_[i]->phis()->at(j);
      // Check for the hole value (from an uninitialized const).
      for (int k = 0; k < phi->OperandCount(); k++) {
        if (phi->OperandAt(k) == GetConstantHole()) return false;
      }
    }
  }
  return true;
}

@mraleph should be able to help explaining it (as always!)

from devtools-docs.

@paolocaminiti
I've tried to reduce your case. It seems we have found out something interesting.
See vhf/v8-bailout-reasons#13

from devtools-docs.

Unsupported let compound assignment

For anyone trying to decode this bailout reason, here's an example:

function example() {
  let x = 0;
  x += 1; // Causes the deopt.
}

Notably, the increment operator ++ does not cause deopt, nor does the following:

function example() {
  let x = 0;
  x = x + 1; // Does NOT cause deopt.
}

Previously, I had interpreted the term compound assignment to mean multiple assignment statements, comma separated, after the same leading let. E.g.

function example() {
  let x = 0, y = 0; // Does NOT cause deopt.
  let a = 0, b = a + x + y; // Does NOT cause deopt.
}

I have not been able to construe a way to trigger the related bailout reason "Unsupported const compound assignment". Given that const variables can't be reassigned, and that "Unsupported let compound assignment" is triggered by post-declaration assignment operators like +=, I'm skeptical that it's possible to trigger this bailout reason at all.

http://stackoverflow.com/questions/34595356/what-does-compound-let-const-assignment-mean

EDIT

"Unsupported const compound assignment" has been removed from V8 as far as I can tell.

from devtools-docs.

Not optimized: TryCatchStatement

Its worth pointing out that in older versions of v8 (e.g. 5.1.281.83) TryCatchStatement seems to be also triggered by functions with no try/catch but a "for...of" construction

from devtools-docs.

#330

from devtools-docs.

``

Edit (sept 2015): This issue is the living documentation for the deopt & bailout reasons provided by Chrome DevTools and the V8 sampling profiler.

Should I care?

A deopt warning is important to consider if:

• You've profiled a slow interaction
• When viewing a Costly Functions / bottom-up / Heavy report of all operations, sorted by self-time, the function is towards the top
• The function has significant self-time. Fixing the deopt will reduce the self-time of this particular function.

What is a deopt?

The optimizing compiler makes for very fast execution, but functions are not always optimized, and it depends on a number of indicators. First, there's four types of function optimization state:

1. Optimized: V8 has identified this function is hot (runs a lot) and has run it through the optimizing compiler so execution is faster.
2. Unoptimized: The function was not identified by V8 to be worth optimizing.
3. Deoptimized (bailout): V8 wanted to optimize this function, but before executing it, the optimizing compiler refused to optimize because it uses some unsupported Javascript feature (e.g. try/catch, for of, or with()) or hits certain limitations.
4. Deoptimized (deopt): V8 wanted to optimize this function, and did successfully send it through the optimizing compiler. However, this already optimized code runs into a situation it did not foresee and cannot handle. (for example: using a negative array key, or a unexpected variable type). V8 then throws away the optimized code, falls back to unoptimized code and tries again later with more information.

These warnings in DevTools will be shown for both 3 and 4.

These deopt affect only that function, and not its children. For example, try/catch is one of the most common warnings. You can address the concern by using a separate function for the body of the try{} block:

These deopt rules change frequency, so always profile before following these rules arbitrarily across your codebase. In try/catch's case, V8's upcoming Turbofan compiler will optimize code that includes a try/catch block. Turbofan is expected to land in Chrome 48.

Related items:

• https://github.com/vhf/v8-bailout-reasons/blob/master/README.md An alternative listing of these bailout reasons
• https://github.com/petkaantonov/bluebird/wiki/Optimization-killers
• https://github.com/thlorenz/v8-perf/blob/master/compiler.md
• V8's Tech lead explaning deopts and bailouts in 2012: https://youtu.be/UJPdhx5zTaw?t=2132

What do each of the reasons mean?

Read the comments below.
Hmm well you to make

from devtools-docs.