"Not optimized" JavaScript profiler bailout reasons

Question

"Not optimized" JavaScript profiler bailout reasons

paulirish opened this issue 10 years ago · 43 comments

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:

Optimized: V8 has identified this function is hot (runs a lot) and has run it through the optimizing compiler so execution is faster.
Unoptimized: The function was not identified by V8 to be worth optimizing.
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.
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.

khyveasna commented 5 years ago

#330

Answer 1 · 2014-01-19T17:45:18.000Z

Want this as well; chiming in for updates.

Answer 2 · 2014-01-20T18:30:30.000Z

"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);

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();
}

Answer 4 · 2014-01-20T18:31:14.000Z

"Not optimized: Bad value context for arguments value"

Example: ?

Possible fix: ?

Answer 5 · 2014-01-20T18:33:51.000Z

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

Answer 6 · 2014-01-20T18:40:58.000Z

very useful. thank you sir.

Answer 7 · 2014-01-20T19:35:55.000Z

"Not optimized: Optimized too many times"

Example: ?

Possible fix: ?

kOptimizedTooManyTimes

Answer 8 · 2014-03-11T07:39:52.000Z

"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

Answer 9 · 2014-03-17T18:49:32.000Z

"Not optimized: assignment to parameter in arguments object"

This is likely either of:

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

// or

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

Answer 10 · 2014-03-19T14:43:43.000Z

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

Answer 11 · 2014-08-12T16:43:43.000Z

"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.

Answer 12 · 2014-08-12T16:49:14.000Z

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

Answer 13 · 2014-08-12T16:50:32.000Z

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?

Answer 14 · 2014-08-12T16:50:52.000Z

@WebReflection good catch!

Answer 15 · 2014-08-12T17:09:28.000Z

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

Answer 16 · 2015-01-06T13:57:47.000Z

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

Answer 17 · 2015-03-25T16:00:30.000Z

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.

Answer 18 · 2015-06-01T19:03:41.000Z

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.

Answer 19 · 2015-06-01T19:54:55.000Z

@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.

Answer 20 · 2015-06-02T18:31:54.000Z

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

Answer 21 · 2015-08-07T01:44:00.000Z

"Not optimized:Yield"

The yield keyword is used in the function body.

Answer 22 · 2015-09-12T05:57:09.000Z

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.

Answer 23 · 2015-09-12T08:06:48.000Z

@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

Answer 24 · 2015-09-12T23:47:29.000Z

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.

Answer 25 · 2015-09-14T10:14:48.000Z

@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.

Answer 26 · 2015-09-14T10:29:14.000Z

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.

Answer 27 · 2015-09-14T11:26:41.000Z

@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 ?

Answer 28 · 2015-09-14T12:21:15.000Z

@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.

Answer 29 · 2015-10-03T01:37:19.000Z

"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.))

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.
As @mraleph indicated above, you can also use IRHydra to find the deoptimized reason:

Answer 30 · 2015-10-13T01:33:04.000Z

"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.

Answer 31 · 2015-10-17T12:08:13.000Z

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);
}

Answer 32 · 2015-10-27T18:56:55.000Z

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

Answer 33 · 2016-01-27T23:07:04.000Z

Not optimized: TryCatchStatement

Cause having a try catch statement within a function block.

Answer 34 · 2016-02-02T15:59:59.000Z

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?

Answer 35 · 2016-10-17T02:33:50.000Z

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

Answer 36 · 2016-10-17T07:36:33.000Z

@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.)

Answer 37 · 2016-10-17T08:00:27.000Z

@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!)

Answer 38 · 2016-12-09T22:30:36.000Z

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.

Answer 39 · 2017-01-29T03:49:28.000Z

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

Answer 40 · 2017-05-10T10:44:56.000Z

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.

Answer 41 · 2017-07-31T15:36:47.000Z

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

Answer 42 · 2019-11-09T18:06:16.000Z

``

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:

Optimized: V8 has identified this function is hot (runs a lot) and has run it through the optimizing compiler so execution is faster.

Unoptimized: The function was not identified by V8 to be worth optimizing.

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.

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