#1 楼
蓝鸟作者在这里。V8承诺实现是用JavaScript而不是C编写的。所有JavaScript（包括V8自己的）都编译为本机代码。此外，在可能的情况下（并且值得）对用户编写的JavaScript进行优化，然后再编译为本机代码。 Promises实现对于使用C编写不会带来任何好处或根本没有任何好处，实际上，这只会使其变慢，因为您要做的只是操纵JavaScript对象和通信。不像bluebird那样优化，它为实例分配了promises处理程序的数组。当每个promise也必须分配几个数组时，这会占用大量内存（基准创建了总共80k个promise，因此分配了160k个未使用的数组）。实际上，99.99％的用例从未多次承诺过，因此针对此常见用例进行优化可以获得巨大的内存使用改进。规范。基准测试必须使用
new Promise（蓝鸟的反模式），因为没有其他方法可以在ES6中创建根本承诺。 new Promise是创建promise的极其慢的方法，首先是executor函数分配一个闭包，其次将2个单独的闭包作为参数传递。这是每个Promise分配的3个闭包，但是闭包已经比优化的Promise更加昂贵。允许在一行中将整个模块转换为基于承诺的模块（promisify）。评论
“仍然受到规范的阻碍”-不知道那是什么意思。您是说ES6遵循的是一种本质上较慢的规范，如果是这样的话，是否就意味着bluebird没有遵循相同的规范（如果是这样，它遵循的是另一种规范吗？并且有什么原因导致ES6除了新的Promise之外没有更好的方法来创建根Promise或改进实例化以使其更便宜（例如每个实例不创建3个闭包）？
–安东尼
2015年6月3日，12：40
这听起来一点也不好（对于JS）。我真的不想在有内部实现时使用Promise库。如果这是真的，对每个人来说这都是不幸的情况。但是无论如何，我已经看不到Promise-hype的麻烦了，我已经编写了100,000个LoC JS应用程序，但是我仍然没有真正的需求，这对我来说是一个非常小的改进，主要是在错误处理方面，回调处理方面的改进（我的编码风格从未经历过“回调地狱”）。
–莫尔
2015年6月15日在8:44
在ES6中，您不能使用Promise.resolve（）创建“根承诺”吗？
– Zetlen
15年11月13日在16:02
@MörreNoseshine（续）多年后，ES6的作者走了过来，并说：“嘿，让我们指定JS引擎必须开箱即用地提供通用的Promises / A +兼容实用程序，因此人们总是可以使用基本的Promise工具”。这是一个很好的便利（不必只是为了快速执行Promise.resolve（）导入库），但这是一个非常基本的实现，它的存在不应该使您停止使用更严重的与承诺相关的工具，例如bluebird ！
– callum
16年1月21日在12:39
@MörreNoseshine100k LOC Javascript应用程序，可能永远没有任何异步功能。祝您编写一个100k的LoC JS游戏好运，它带有一个没有bluebird的mysql / redis库。
– NiCk Newman
16 Mar 7 '16 at 15:26
评论
请记住，现代的JavaScript实现已经过高度优化，甚至可以使用JIT在本地运行。根据此基准，BlueBirdJS实际上比Native Promises慢。但是，PromiseMeSpeedJS实际上超过了两者。 PromiseMeSpeedJS借此证明的许多事情之一是，对PromiseMeSpeedJS的滥用是因为PromiseMeSpeedJS不使用new运算符，所以对诺言的主要表现是滥用运算符。
@JackGiffin Chrome 67：PromiseMeSpeedJS慢46％，蓝鸟慢61％。