-
Notifications
You must be signed in to change notification settings - Fork 179
"Not optimized" JavaScript profiler bailout reasons #53
Comments
Want this as well; chiming in for updates. |
"Not optimized: Inlining bailed out"Examplevar obj = { prop1: ..., prop2: ... };
function f(obj) {
obj.someOtherProp = ...;
}
f(obj); or: function someMethodThatAssignsSomeOtherProp(obj) {
obj.someOtherProp = ...;
}
function f(obj) {
someMethodThatAssignsSomeOtherProp(obj);
}
f(obj); Possible fixvar obj = { prop1: ..., prop2: ..., someOtherProp: ... };
f(obj); |
What: "Not optimized: ForInStatement is not fast case"Examplefor (var prop in obj) {
/* lots of code */
} Possible fixfunction f() {
/* lots of code */
}
for (var prop in obj) {
f();
} |
"Not optimized: Bad value context for arguments value"Example: ?Possible fix: ? |
(just pasting some notes; perhaps will come in useful) |
very useful. thank you sir. |
"Not optimized: Optimized too many times"Example: ?Possible fix: ? |
"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. Examplefunction 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.
see link for more |
"Not optimized: assignment to parameter in arguments object"This is likely either of: (function() {
arguments[0] = ...;
})();
// or
(function(foo, bar) {
foo = ...
})(); |
I posed the question on SO - http://stackoverflow.com/questions/22509262/what-do-the-not-optimized-warnings-in-the-chrome-profiler-mean |
"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. |
@twokul the first parameter for |
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? |
@WebReflection good catch! |
then in the STRICTLY .apply part in special |
I have also the problem about the |
We've landed a bunch of patches recently to expose deopt reasons: |
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. |
@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. |
Hm... if that's the case, I wonder if initializing the property to undefined would help. |
"Not optimized:Yield"The |
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. |
@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 |
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. |
@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. |
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. |
@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 ? |
@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. |
"Not optimized: Unsupported phi use of const or let variable"? |
@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.) |
@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!) |
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. |
@paolocaminiti |
I was profiling the css() function and Chrome raised a flag on this function: > Not optimized: Bad value context for arguments value More info on this warning: GoogleChrome/devtools-docs#53 (comment) Looking at the warning and the compiled version of this code, it seems to do some things with `arguments` when using the default values here, which is causing this deoptimization. ```js var selectorHandlers = arguments.length <= 2 || arguments[2] === undefined ? [] : arguments[2]; var stringHandlers = arguments.length <= 3 || arguments[3] === undefined ? {} : arguments[3]; var useImportant = arguments.length <= 4 || arguments[4] === undefined ? true : arguments[4]; ``` By removing the default values for the arguments, the deoptimization disappears. I thought about adding logic that would provide values for these arguments if they aren't defined, but since the only thing that relies on that is tests I decided to just update the tests to always pass all of the arguments. In my benchmark, this does not seem to make much of a difference but it still seems like a good idea to avoid things that the browser tells us is deoptimized.
I was profiling the css() function and Chrome raised a flag on this function: > Not optimized: Bad value context for arguments value More info on this warning: GoogleChrome/devtools-docs#53 (comment) Looking at the warning and the compiled version of this code, it seems to do some things with `arguments` when using the default values here, which is causing this deoptimization. ```js var selectorHandlers = arguments.length <= 2 || arguments[2] === undefined ? [] : arguments[2]; var stringHandlers = arguments.length <= 3 || arguments[3] === undefined ? {} : arguments[3]; var useImportant = arguments.length <= 4 || arguments[4] === undefined ? true : arguments[4]; ``` By removing the default values for the arguments, the deoptimization disappears. I thought about adding logic that would provide values for these arguments if they aren't defined, but since the only thing that relies on that is tests I decided to just update the tests to always pass all of the arguments. In my benchmark, this does not seem to make much of a difference but it still seems like a good idea to avoid things that the browser tells us is deoptimized.
Unsupported let compound assignmentFor 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 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 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 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. |
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 |
``
|
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:
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:
try/catch
,for of
, orwith()
) or hits certain limitations.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 thetry{}
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 atry/catch
block. Turbofan is expected to land in Chrome 48.Related items:
What do each of the reasons mean?
Read the comments below.
The text was updated successfully, but these errors were encountered: