javascript - 确定去优化的原因

Question

首先是问题:

如何确定我的函数去优化的原因？

例如，这是我的一个函数的去优化条目:

[deoptimizing (DEOPT eager): begin 0x3ca09e9f4d1 mergeObjects (opt #50) @12, FP to SP delta: 96]
            ;;; jump table entry 8: deoptimization bailout 12.
  translating mergeObjects => node=43, height=64
    0x7fff5fbfecd0: [top + 128] <- 0xcd290004121 ; [sp + 144] 0xcd290004121 <undefined>
    0x7fff5fbfecc8: [top + 120] <- 0x3ca09e9ca19 ; [sp + 136] 0x3ca09e9ca19 <an Object with map 0x4c8d818621>
    0x7fff5fbfecc0: [top + 112] <- 0x2c9b8b1b95a9 ; [sp + 128] 0x2c9b8b1b95a9 <an Object with map 0x7e33a207821>
    0x7fff5fbfecb8: [top + 104] <- 0x2c9b8b1b9229 ; rax 0x2c9b8b1b9229 <JS Array[0]>
    0x7fff5fbfecb0: [top + 96] <- 0xcd290004181 ; [sp + 112] 0xcd290004181 <false>
    0x7fff5fbfeca8: [top + 88] <- 0x2481f54fb4b6 ; caller's pc
    0x7fff5fbfeca0: [top + 80] <- 0x7fff5fbfed40 ; caller's fp
    0x7fff5fbfec98: [top + 72] <- 0x3ca09e8eae1; context
    0x7fff5fbfec90: [top + 64] <- 0x3ca09e9f4d1; function
    0x7fff5fbfec88: [top + 56] <- 0x70a69429aa1 ; [sp + 32] 0x70a69429aa1 <String[3]: key>
    0x7fff5fbfec80: [top + 48] <- 0xcd290004121 <undefined> ; literal
    0x7fff5fbfec78: [top + 40] <- 0xcd290004121 <undefined> ; literal
    0x7fff5fbfec70: [top + 32] <- 0x3ca09e9ca19 ; [sp + 136] 0x3ca09e9ca19 <an Object with map 0x4c8d818621>
    0x7fff5fbfec68: [top + 24] <- 0x4c8d818621 ; [sp + 64] 0x4c8d818621 <Map(elements=3)>
    0x7fff5fbfec60: [top + 16] <- 0x2c9b8b014341 ; [sp + 56] 0x2c9b8b014341 <FixedArray[3]>
    0x7fff5fbfec58: [top + 8] <- 0x300000000 ; [sp + 48] 3
    0x7fff5fbfec50: [top + 0] <- 0 ; [sp + 40] (smi)
[deoptimizing (eager): end 0x3ca09e9f4d1 mergeObjects @12 => node=43, pc=0x2481f54ecd00, state=NO_REGISTERS, alignment=no padding, took 0.060 ms]
[removing optimized code for: mergeObjects]

我怀疑原因是这样的:

jump table entry 8: deoptimization bailout 12.

我在哪里可以找到关于这个和其他去优化原因的更多信息？更重要的是，我如何确定我的 JS 代码的哪一部分导致了这种去优化？

以下是我看到的其他函数的一些其他去优化原因:

• 去优化:通用命名访问的类型反馈不足
• 去优化:二进制操作的 RHS 类型反馈不足
• 跳转表条目 X:去优化救助 Y。 - 其中很多具有​​不同的编号

通俗地说，我希望能够查看此日志并说“好吧，我的函数被去优化了，因为 v8 预测我将只使用字符串作为它的函数参数，在这里我用一个整数调用它”(或类似的东西)。

我还想详细了解我可以在这些日志中看到的其他信息 - 例如，各种去优化意味着什么(eager、soft 等)？第一行的数字是什么意思？在提高性能的同时，我还应该对该日志中的哪些内容感兴趣？

如果它以任何方式相关，则上面日志中取消优化的代码是 here并生成日志(通过运行库的基准测试)，在项目的根目录中执行:

node --trace_deopt --code_comments bench

Answer 1

Petka Antonov( bluebird 的创造者)describes some optimization killers here .我不知道如何解释您的 V8 输出，但是 your code确实包含一个 for-in 循环，在某些情况下会导致去优化。例如，如果被迭代的对象在 hashtable mode 中.来自文章:

An object will go into hash table mode for example when you add too many properties dynamically (outside constructor), delete properties, use properties that cannot be valid identifiers and so on. In other words, when you use an object as if it was a hash table, it will be turned into a hash table. Passing such an object to for-in is a no no. You can tell if an object is in hash table mode by calling console.log(%HasFastProperties(obj)) when the flag --allow-natives-syntax is enabled in Node.JS.

这种级别的 V8 优化确实看起来像是某种黑暗艺术 :) 希望对您有所帮助!