Toggle navigation
MeasureThat
.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
sync vs promise
(version: 0)
Comparing performance of:
sync vs promise
Created:
5 years ago
by:
Guest
Go to the latest result
Script Preparation code:
var sync = (foo) => { return foo; }; var promise = (foo) => { return Promise.resolve(foo); };
Tests:
sync
(function () { sync('test'); })();
promise
(async function () { await promise('test'); })();
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (2)
Previous results
Fork
Test case name
Result
sync
promise
Fastest:
N/A
Slowest:
N/A
Latest run results:
Run details:
(Test run date:
one year ago
)
User agent:
Mozilla/5.0 (iPhone; CPU iPhone OS 18_3_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.3.1 Mobile/15E148 Safari/604.1
Browser/OS:
Mobile Safari 18 on iOS 18.3.2
View result in a separate tab
Embed
Embed Benchmark Result
<iframe src="https://measurethat.net/Embed?id=599694" width="100%" height="500px"></iframe>
sync
146.8M/s
promise
6.5M/s
View exact numbers
Test name
Executions per second
✓
sync
146,802,992 Ops/sec
promise
6,466,930 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
Let's dive into the explanation of the provided benchmark. **Overview** The benchmark measures the performance difference between synchronous and asynchronous code execution in JavaScript. The test case uses two functions: `sync` and `promise`, which return the input value as is, with the former being a synchronous function and the latter using Promises to handle asynchronous execution. **Script Preparation Code** The script preparation code defines the two functions: * `sync`: takes an argument `foo` and returns it directly. * `promise`: also takes an argument `foo` and returns a resolved Promise with the input value. This is done using the `Promise.resolve()` method, which creates a new Promise that is immediately resolved. The purpose of these functions is to encapsulate simple synchronous and asynchronous code blocks that will be used for benchmarking. **Options Compared** Two options are compared: 1. **Synchronous Execution (sync)**: executes the code synchronously, meaning it waits for the execution to complete before moving on. 2. **Asynchronous Execution with Promises (promise)**: uses Promises to execute the code asynchronously, allowing other tasks to run while waiting for the Promise to resolve. **Pros and Cons** * **Synchronous Execution (sync)**: + Pros: - Easier to understand and debug, as execution is sequential. - No overhead of creating a new thread or context. + Cons: - Can block the main thread, leading to poor performance and responsiveness. - May not be suitable for I/O-bound tasks or those with high latency. * **Asynchronous Execution with Promises (promise)**: + Pros: - Allows other tasks to run while waiting for the Promise to resolve, improving responsiveness. - Can handle I/O-bound tasks and high-latency operations more efficiently. + Cons: - Requires more code and can be less straightforward to understand and debug. - May introduce additional overhead due to the creation of a new thread or context. **Other Considerations** * **Library Usage**: The test case uses the built-in `Promise` object, which is a part of the JavaScript standard library. Promises provide a way to handle asynchronous operations in a more efficient and manageable manner. * **Special JS Feature/Syntax**: None mentioned in this specific benchmark. **Alternatives** Other alternatives for asynchronous code execution include: 1. **Async/Await**: While not used in this benchmark, async/await is another syntax sugar on top of Promises that allows writing asynchronous code that looks more synchronous and easier to understand. 2. **Web Workers**: If the task is CPU-bound or requires low-level memory manipulation, web workers can be used to execute the code in a separate thread, improving performance and responsiveness. 3. **Cooperative scheduling**: Some frameworks and libraries use cooperative scheduling to yield control back to the main thread after executing an I/O-bound operation, allowing for more efficient use of resources. Keep in mind that each alternative has its own trade-offs and requirements, and the choice ultimately depends on the specific use case and performance characteristics.
Related benchmarks
Promise vs. Callback
Promise vs async vs callbacks
callbacks vs promises vs async/awaits
Async vs Callback
Comments
Confirm delete:
Do you really want to delete benchmark?