今年5月、Denoは、プロジェクトのフロントエンドを構築するためにNodeの頻繁な使用として、バージョン1.0をリリースし、Denoの公式ウェブサイトは、それらの利点は、実際にはあまり気にしない説明しています。主にどのようにDenoのパフォーマンスを知りたい、Denoで大幅にフロントエンドのビルドプロジェクト時間のかかる減らすことができます。ネットワーク上でDenoは、Nodeの議論もより興味を持って置き換えることができますので、彼らはいくつかの一般的なメソッドを実行するためにDenoとNodeを使用し、それらのパフォーマンスを比較し、DenoはNodeを置き換えることができるかどうかを研究します。
Deno
DenoはJavaScriptとTypeScriptのランタイムで、NodeやJavaと同じようにサーバー上で実行できます。
テスト情報
Node version v14.6.0 (v8-8.4.371.19)、Deno version 1.1.0 (v8-8.4.300)。
実行結果は、同じメソッドを5回実行することで範囲を取得しました。
サードパーティライブラリはspark-md5、js-base64、acorn、estraverse、escodegenを使用。
sort による配列の並べ替え
console.time("sort-array");
dataArray.sort((a, b) => {
return a - b;
});
console.timeEnd("sort-array");
ノード：84.645ms～103.086ms
デノ：134ms～140ms
md5（ファイルサイズ2.6M）
console.time('md5');
spark.append(data);
console.log('md5:\x20' + spark.end());
console.timeEnd('md5');ノード 33.559ms-41.608ms
デノ 63ms-83ms
base64 (ファイルサイズ 2.6M)
console.time('Base64');
Base64.encode(data);
console.timeEnd('Base64');ノード 572.197ms-662.004ms
デノ 1216ms-1269ms
フィボナッチ数列
function a(obj) {
if (obj === 0x0) {
return 0x0;
} else if (obj === 0x1) {
return 0x1;
} else {
return a(obj - 0x1) + a(obj - 0x2);
}
}
console.time('fib');
a(0x28);
console.timeEnd('fib');ノード 1.286s-1.343s
デノ 1447ms-1616ms
for in はオブジェクトを走査します。
console.time('for\x20in');
for (let a in dataObject) {
total += dataObject[a].list[0x0].n;
}
console.timeEnd('for\x20in');ノード 49.773ms-65.803ms
デノ 41ms-49ms
JSON
console.time('JSON');
let c = JSON.parse(JSON.stringify(dataObject));
console.timeEnd('JSON');ノード 345.198ms-376.225ms
デノ 173ms-192ms
カスタムローダー（約202ファイル生成）
上記のテストコードはすべてKokoあり、テスト結果は異なるはずですが、違いの大きさは正確なはずです。ご自分のコンピューターで試してみてください。
パフォーマンス比較分析
上記のデータから、配列のソート、オブジェクトのトラバーサル、再帰的な関数呼び出し、md5計算、およびbase64エンコーディングのテストではNodeの方が優れており、JSONシリアライゼーションとカスタムローダーのテストではDenoの方が優れていることがわかります。
webpackでパッケージ化した場合、カスタムローダーのテストウェイトが他の項目よりも高くなるはずなので、Denoでパッケージ化した場合でも、データ上は20%程度まで一定の改善が見込めるはずです。もちろん、この結論は正確ではありません、実際のwebpackの処理の開発はまだより複雑であり、本当の正確な比較はまだWebpackを実装するためにDenoを使用することです。例えば、RollupとParcelはどちらもパッケージング効率がwebpackよりはるかに高いと宣伝していましたが、今ではビルドツールのリーダーとしてのwebpackの地位を揺るがすことはできません。
そのため、先行者の優位性は依然として非常に重要です。現在、NodeのサーバーサイドフレームワークにはExpressがあり、ビルドツールにはwebpackがあり、デスクトップアプリケーションにはelectronがあります。そして、Denoの公式ウェブサイトのドキュメントから、Nodeではなく、Pythonのシナリオの一部を置き換えることがわかります。
Deno経験
まず、Denoはtypescriptファイルを直接実行できるので、最初にtscでコンパイルする必要がありません。関数のデフォルトがプロミスを返すので、直接awaitを使うことができます。インポート()やウェブワーカーをサポートしているので、ブラウジングの経験者とかでも簡単に使い始めることができます。
全体的な使い心地はとても良く、Nodeに比べてビルドの手間が省けます。
しかし、Denoは現時点では成熟しておらず、いくつかのAPIはまだ不安定で、提供されているAPIは少なすぎます。また、osモジュールの一部のメソッドなど、実装できないものもあります。サードパーティモジュールも比較的少なく、現在786個しかありません。こちら確認できます。
ですから、Denoがバージョン1.0をリリースしたとはいえ、本番で使えるようになるにはまだ時間がかかりそうです。
まとめ
- リファクタリングのコストとエコロジーの強さを考慮すると、DenoのパフォーマンスはNodeを置き換えることは困難です。
- Denoも一部のユーザーを取り込むべきだし、Denoの良さに興味を持っている人はかなりいるし、Denoの学習コストはまだ比較的低い。
- Denoのエコシステムはまだ未成熟であり、システム方法論とサードパーティライブラリはまだ比較的小さいため、企業が本番環境でDenoを使用することは推奨されません。
帰属表示を伴う転載は十分可能です。
この記事は、一部のメソッドの速度を比較しているだけであり、2つの言語自体のパフォーマンスを表しているわけではありません。サーバーサイドのパフォーマンスについては、Denoのウェブサイトで比較結果をご覧ください。
