Despite the existence of the ESLint rule no-return-await, which discourages the use of return await, some developers may find themselves utilizing this pattern. While it does not pose a significant performance issue, the rule's description mentions that return await introduces "extra time before the overarching Promise resolves or rejects."
However, the MDN documentation's "Simple Example" demonstrates the use of return await without implying any performance concerns. To shed light on this discrepancy, let's explore the actual impact of return await.
In essence, return await is a redundant operation. The Promise resolution or rejection already occurs within the async function, and return await simply waits for it again before returning the value. This additional operation can potentially add minimal execution time, but it is unlikely to have a noticeable impact on performance.
One instance where return await does make a meaningful difference is in exception handling:
try { ... return await ...; } ...
When using await, rejections within the async function trigger an exception, ensuring that the catch and finally handlers are executed. However, a plain return would simply exit the try block and skip these handlers.
While return await is not a performance problem in general, it is considered poor style and may indicate a lack of understanding of promises and async/await. In most cases, it is unnecessary and should be avoided. However, in the context of error handling, return await becomes essential for proper exception propagation.
The above is the detailed content of Is `return await` a Performance Bottleneck?. For more information, please follow other related articles on the PHP Chinese website!