ネイティブのES6がbluebirdよりも遅く、より多くのメモリを消費するのはなぜですか？

ではこのベンチマーク、スイートは、ブルーバード約束に比べES6の約束を完了するまでに4倍の時間がかかり、多くのメモリと3.6倍を使用しています。

JavaScriptライブラリは、Cで記述されたv8のネイティブ実装よりもはるかに高速で軽量になります。Bluebirdのpromiseは、ネイティブのES6のpromiseとまったく同じAPIを備えています（さらに、多数の追加のユーティリティメソッド）。

ネイティブの実装は間違って書かれているだけですか、それとも私が見逃している他の側面がありますか？

Bluebirdの著者はこちら。

V8は実装が CではなくJavaScriptで記述されることを約束します。すべてのJavaScript（V8自体を含む）はネイティブコードにコンパイルされます。さらに、ネイティブコードにコンパイルされる前に、可能であれば（そしてそれだけの価値がある）ユーザー作成のJavaScriptが最適化されます。Promiseの実装は、Cで記述されてもあまりメリットがないか、まったく役に立たないものです。実際、JavaScriptオブジェクトと通信を操作するだけなので、遅くなります。

V8実装は単純にbluebirdほど最適化されておらず、インスタンス用にpromiseのハンドラーに配列を割り当てます。各プロミスがいくつかの配列を割り当てる必要がある場合、これは多くのメモリを消費します（ベンチマークは全体で80k個のプロミスを作成するため、160k個の未使用配列が割り当てられます）。実際には、ユースケースの99.99％が複数回約束を分岐することはないため、この一般的なケース向けに最適化すると、メモリ使用量が大幅に改善されます。

V8がbluebirdと同じ最適化を実装したとしても、仕様によって妨げられます。new PromiseES6でルートプロミスを作成する他の方法がないため、ベンチマークでは（bluebirdのアンチパターン）を使用する必要があります。new Promiseは、約束を作成する非常に遅い方法です。まず、executor関数がクロージャーを割り当て、次に引数として2つの別々のクロージャーが渡されます。約束ごとに3つのクロージャーが割り当てられますが、クロージャーはすでに最適化された約束よりも高価なオブジェクトです。

Bluebirdはpromisify、多くの最適化を可能にし、コールバックAPIを消費するはるかに便利な方法を使用でき、1行でモジュール全体をpromiseベースのモジュールに変換できます（promisifyAll(require('redis'));）。