「return await」はパフォーマンスのボトルネックですか?

return await のパフォーマンスへの影響

return await の使用を妨げる ESLint ルール no-return-await が存在するにもかかわらず、一部の開発者は return await を利用していることに気づくかもしれません。このパターン。パフォーマンスに重大な問題を引き起こすわけではありませんが、ルールの説明には、return await によって「包括的な Promise が解決または拒否されるまでの余分な時間」が生じると記載されています。

ただし、MDN ドキュメントの「Simple Example」では return の使用法を示しています。パフォーマンス上の懸念を示唆することなく待機します。この矛盾を明らかにするために、return await の実際の影響を調べてみましょう。

return await はパフォーマンスの問題ですか?

本質的に、return await は冗長な操作です。 Promise の解決または拒否は async 関数内ですでに発生しており、return await は値を返す前に再度それを待つだけです。この追加操作により、最小限の実行時間が追加される可能性がありますが、パフォーマンスに顕著な影響を与える可能性は低いです。

例外的なケース: エラー処理

return await が意味のある違いを生む 1 つの例は、次のとおりです。例外処理:

try {
    ...
    return await ...;
} ...

await を使用する場合、非同期関数内の拒否により例外がトリガーされ、catch ハンドラーとfinally ハンドラーが確実に実行されます。ただし、単純な return は単に try ブロックを終了し、これらのハンドラーをスキップします。

結論

return await は一般にパフォーマンスの問題ではありませんが、スタイルが悪いと考えられており、欠陥があることを示している可能性があります。 Promise と async/await の理解。ほとんどの場合、これは不必要なので、避ける必要があります。ただし、エラー処理のコンテキストでは、例外を適切に伝播するために return await が不可欠になります。

以上が「return await」はパフォーマンスのボトルネックですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。