Toggle navigation
MeasureThat
.net
Create a benchmark
Tools
Feedback
Feature Requests
FAQ
Register
Log In
arr.at(index) vs arr[index]
(version: 0)
Benchmark.js
Comparing performance of:
at vs bracket notation
Created:
3 years ago
by:
Guest
Go to the latest result
Script Preparation code:
const LENGTH = 10000; var arr = new Array(LENGTH); for (let i = 0; i < LENGTH; i++) { arr[i] = i * 5; }
Tests:
at
arr.at(753);
bracket notation
arr[753];
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (2)
Previous results
Fork
Test case name
Result
at
bracket notation
Fastest:
N/A
Slowest:
N/A
Latest run results:
Run details:
(Test run date:
one year ago
)
User agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
Browser/OS:
Chrome 140 on Mac OS X 10.15.7
View result in a separate tab
Embed
Embed Benchmark Result
at
280.3M/s
bracket notation
257.1M/s
View exact numbers
Test name
Executions per second
✓
at
280,331,872 Ops/sec
bracket notation
257,133,712 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
Let's dive into explaining the provided JavaScript microbenchmark, MeasureThat.net. **Benchmark Definition and Purpose** The benchmark measures the performance of accessing elements in an array using two different approaches: `arr.at(index)` and `arr[index]`. The purpose is to compare the efficiency of these two methods. **Options Compared** There are two options being compared: 1. `arr.at(index)` 2. `arr[index]` **Pros and Cons of Each Approach** * `arr.at(index)`: This method uses the `at()` function, which was introduced in ECMAScript 2019. It provides a safer way to access array elements by throwing a `TypeError` if the index is out of bounds. + Pros: Provides better error handling, more explicit syntax. + Cons: May incur additional overhead due to the `TypeError` check. * `arr[index]`: This method uses direct array indexing using square brackets (`[]`). + Pros: Fast and simple, well-established syntax. + Cons: No error checking, may lead to runtime errors if index is out of bounds. **Other Considerations** When accessing array elements, other factors that might affect performance include: * Array length and density (i.e., how densely populated the array is). * The browser's optimization techniques for array access. * The availability of advanced features like WebAssembly or Just-In-Time (JIT) compilation. **Library and Special JS Feature** There is no library used in this benchmark. However, the `at()` function, which is being compared to direct indexing, is a special JavaScript feature introduced in ECMAScript 2019. **Benchmark Preparation Code** The preparation code creates an array of length 10,000 and populates it with values from 0 to 49,999 (i.e., each element is multiplied by 5). **Individual Test Cases** There are two test cases: 1. `arr.at(753)`: This tests the performance of accessing a specific element at index 753 using the `at()` function. 2. `arr[753]`: This tests the performance of accessing the same element at index 753 using direct array indexing. **Benchmark Results** The latest benchmark results show that: * `arr.at(753)` has an execution rate of approximately 285,501,780 per second on a Desktop with Opera 102 browser. * `arr[753]` has an execution rate of approximately 284,513,760 per second on the same setup. In general, direct array indexing (`arr[index]`) tends to be faster than using the `at()` function due to the additional overhead introduced by error checking. However, the performance difference may vary depending on specific use cases and browser implementations.
Related benchmarks
Reading array length inside vs outside for loop
Array.Prototype.at vs index
Comments
Confirm delete:
Do you really want to delete benchmark?