确定去优化的原因
首先，这个问题：
我怎样才能确定我的function去优化的原因？
例如，下面是我的一个function的去优化条目：
[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] 我怀疑这个原因虽然不是很有说服力，
跳表条目8：优化救助12。
我在哪里可以find关于这个和其他去优化理由的更多信息？ 更重要的是， 我怎样才能确定我的JS代码的哪部分导致了这种去优化？
以下是其他function的其他去优化原因：
-
deoptimize: Insufficient type feedback for generic named access -
deoptimize: Insufficient type feedback for RHS of binary operation -
jump table entry X: deoptimization bailout Y.– 大量不同的数字
通俗地说，我希望能够看到这个日志，并说：“ 好吧，我的函数得到了去优化，因为v8预测我只会使用string作为它的函数参数，在这里我用一个整数 ”（或类似的东西） 。
我还想更多地了解我在这些日志中可以看到的其他信息 – 例如，各种去优化是什么意思（急切，软弱等）？ 第一行的数字是什么意思？ 在改善性能的同时，我还应该对这个日志有什么兴趣？
如果它有任何相关性，那么上面日志中的优化代码就在这里，并生成日志（通过运行库的基准），在项目的根目录下执行：
node --trace_deopt --code_comments bench
佩特卡·安东诺夫（蓝鸟的创造者） 在这里描述了一些优化杀手 。 我不知道如何解释你的V8输出，但是你的代码确实包含了一个for-in循环，这可能导致在某些情况下的优化。 例如，如果被迭代的对象是散列表模式 。 从写作：
例如，当dynamic添加太多属性（构造函数外），删除属性，使用不能成为有效标识符的属性等等时，对象将进入散列表模式。 换句话说，当你使用一个对象，就好像它是一个散列表一样，它将会变成一个散列表。 传递这样的对象是一个不行的。 在Node.JS中启用标志–allow-natives-syntax时，可以通过调用console.log（％HasFastProperties（obj））来判断对象是否处于散列表模式。
这个级别的V8优化绝对看起来像某种黑暗的艺术:)希望有所帮助！