> v8 optimizer (crankshaft) inlines the functions whose body length, including the comments, is less than 600 characters.

In what kind of world is that a sensible metric to decide if a function can be inlined?

In the world where you have to make these decisions quickly, and don't have time to parse the function.

I don't buy it: that would only make sense if you could copy/paste the source or something, and even JS respects function scoping so you can't. You'd have to wait until later anyway, so why not count AST nodes or something instead?

I can't make useful guesses about the V8 developers' reasoning, but I'd assume they considered several options and chose this one for a reason, concerning how much performance is at stake. I don't know about Crankshaft's inner workings, though, so I can't make qualified comments about it. Maybe something like http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op... can answer some of your questions?

Thanks. Quick CTRL+F for "inlining" produces:

> Graph generation: Crankshaft builds the Hydrogen control flow graph using the AST, scope info, and type feedback data extracted from the full-compiled code. Inlining also happens at this stage. Hydrogen is Crankshaft's high-level architecture-independent intermediate representation.

> Inlining: Performed during the graph generation phase. The inlining heuristic is very simple: basically, if the function being called is known, and it is safe to inline, the function will be inlined. Large functions (>600 source characters including whitespace or 196 AST nodes) will not be inlined. Cumulatively, a total of 196 AST nodes can be inlined in a single function.

So they do use AST nodes as a heuristic; I don't really understand why they would also use "source characters including whitespace" though.

Guess I better keep my comments outside the function body from now on when possible.

In the "I need to do this quickly to finish my sprint" world.

Wasn't V8 written in a cottage in Denmark? http://www.ft.com/cms/s/0/03775904-177c-11de-8c9d-0000779fd2... I cannot imagine that they would take unreasonable shortcuts.

Well, unreasonable now was probably perfectly reasonable at the time of implementation. Perhaps they even have or had a plan to improve upon it, but given other tasks (ES6, etc.) it hasn't been given much priority.

I mean, why would they fix it with high priority if the engine already has reasonable performance and the benchmarks are happy as well?

Even then, why include comments? Is it to support stuff like multi-line strings as comments hack[1]?

[1]: https://github.com/sindresorhus/multiline