Toggle navigation
MeasureThat
.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
Async vs Callback
(version: 0)
Comparing performance of:
Async vs Promises
Created:
2 years ago
by:
Guest
Go to the latest result
Tests:
Async
(async () => { return true; })();
Promises
(() => new Promise((res, rej) => res(true)))();
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (2)
Previous results
Fork
Test case name
Result
Async
Promises
Fastest:
N/A
Slowest:
N/A
Latest run results:
Run details:
(Test run date:
one year ago
)
User agent:
Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0
Browser/OS:
Firefox 137 on Linux
View result in a separate tab
Embed
Embed Benchmark Result
<iframe src="https://measurethat.net/Embed?id=600941" width="100%" height="500px"></iframe>
Async
12.7M/s
Promises
9.6M/s
View exact numbers
Test name
Executions per second
✓
Async
12,742,920 Ops/sec
Promises
9,609,417 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
**Benchmark Overview** The provided JSON represents a JavaScript microbenchmark that compares the performance of asynchronous code versus callback-based code. The benchmark is designed to measure the execution speed of small chunks of code in various browsers. **Script Preparation Code and Html Preparation Code** Unfortunately, the provided JSON does not contain any script preparation code or HTML preparation code. This means that the benchmark assumes that a basic JavaScript environment with no additional dependencies or configurations is already set up for each test case. **Test Cases** There are two test cases: 1. **Async**: The first test case measures the execution speed of an asynchronous function using the `async/await` syntax. ```javascript (async () => { return true; })(); ``` This code defines a small asynchronous function that simply returns a value without any blocking or I/O operations. 2. **Promises**: The second test case measures the execution speed of a promise-based implementation, which is equivalent to the first test case but uses the promise API instead: ```javascript (() => new Promise((res, rej) => res(true)))(); ``` This code defines a small function that returns a promise that resolves to `true`. **Options Compared** The benchmark compares two approaches: 1. **Async/await**: This approach uses asynchronous functions and the `async` keyword to define a function with an asynchronous execution context. 2. **Promises**: This approach uses the promise API to create a promise that can be executed asynchronously. **Pros and Cons of Each Approach** Here are some pros and cons of each approach: * **Async/Await**: + Pros: - More readable and easier to write code for asynchronous operations - Less error-prone, as errors in the await expression are more apparent + Cons: - May not be supported by older browsers or JavaScript engines - Can be slower due to the overhead of creating and managing promises * **Promises**: + Pros: - Widespread support across modern browsers and JavaScript engines - More flexible and customizable than async/await + Cons: - More verbose and error-prone than async/await - Requires more manual management of promise states (e.g., resolved, rejected) **Library Usage** There is no library usage in the provided test cases. However, some libraries might be used in the script preparation code or HTML preparation code to set up the testing environment. **Special JS Features or Syntax** There are no special JavaScript features or syntaxes mentioned in the provided benchmark definition or individual test cases. **Other Alternatives** If you want to add more test cases or modify the existing ones, here are some alternative approaches and considerations: * **Synthetic timers**: Instead of using native asynchronous functions or promises, you could use synthetic timers (e.g., `setInterval`, `setTimeout`) to introduce delays and simulate asynchronous operations. * **Different browsers or engines**: You could add test cases that target specific browsers or JavaScript engines (e.g., Safari, Firefox, Node.js) to compare their performance. * **Additional error scenarios**: You could add more complex error scenarios (e.g., unhandled promise rejections, errors in the async/await expression) to make the benchmark more comprehensive. To create a new benchmark, you would need to update the `Benchmark Definition` JSON with new test cases and potentially modify the script preparation code or HTML preparation code to set up the desired testing environment.
Related benchmarks
promise vs callback
just promise vs just callback
Promise vs async vs callbacks
callbacks vs promises vs async/awaits
Comments
Confirm delete:
Do you really want to delete benchmark?