`return await`にパフォーマンスの問題がありますか？

eslint rule, no-return-await, for disallowing return awaitがあります。`return await`にパフォーマンスの問題がありますか？

ルールの説明では、return awaitに"extra time before the overarching Promise resolves or rejects"が追加されています。

しかし、私がMDN async function docsを見ると、「単純な例」には、なぜこれが悪いアイデア/パフォーマンスの問題であるかの説明がなく、return awaitという例が含まれています。

return awaitは、eslintドキュメントのように実際のパフォーマンスに問題がありますか？

もしそうなら、どうですか？

2017-04-11 sfletche

私が知っている限り、 'return'と' return await'は機能的に同等でなければならないので、なぜ合理的な通訳が最初にこれを最適化するべきではないのか分かりません。私は、トランスミッタがこの最適化を行うとは思わない（少なくとも、[Babelはしない]（https://babeljs.io/repl/#?babili=false&evaluate=false&lineWrap=false&presets=stage-2&targets=&browsers=&builtIns=false&code） = async％20function％20foo（）％20％7B％0A％20％20return％20Promise.resolve（123）％3B％0A％7D％0A％0Aasync％20function％20bar（）％20％7B％0A％20％ 20％削減、20％削減、20％削減、20％削減、20％削減、30％削減） – Frxstrem

も参照してください['return await promise'と' return promise'の違い]（https://stackoverflow.com/q/38708550/1048572） – Bergi

いいえ、パフォーマンスはありません問題です。単なる不要な余分な操作です。実行にはもう少し時間がかかるかもしれませんが、ほとんど目立たないはずです。整数xの場合はreturn xの代わりにreturn x+0に似ています。正確にはthe pointless .then(x => x)に相当します。

それは実際に害を行いませんが、私はそれを悪いスタイルと著者は完全にCOMPRE HENDの約束とasync/awaitないというサインを検討したいです。

しかし、それは重要な違い作る一つのケースがあります：

try { 
    … 
    return await …; 
} …

awaitが拒否に投げる、とcatchまたはfinallyハンドラが実行される前に、どのような場合には約束の解決を待ってんで。平文のreturnはそれを無視していました。

出典

2017-05-15 16:59:58 Bergi

`return await`にパフォーマンスの問題がありますか？

答えて

関連する問題