Benchmark: Object key access vs array finds

Script Preparation code:

var items = Array.from(Array(1000), (_,x) => ({key: x, value: x*10}));

var objContainer = {};
var arrContainer = [];
var mapContainer = new Map();

for (let i = 2000; i >= 0; i--) {
  const index = Math.floor(Math.random() * 1000);
  const item = items[index];
  objContainer[item.key] = item;
  arrContainer.push(item);
  mapContainer.set(item.key,item);
}

Tests:

object
items.forEach(item => objContainer[item.value])
map
items.forEach(item => mapContainer.get(item.value))
array
items.forEach(item => arrContainer.find(containerItem => containerItem.value === item.value))

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
object
map
array

Fastest: N/A

Slowest: N/A

Latest run results:

No previous run results

This benchmark does not have any results yet. Be the first one to run it!

Autogenerated LLM Summary (model llama3.1:latest, generated one year ago):

LLMs can make mistakes. Check important info.

Let's dive into the provided JSON and explore what is being tested.

**Benchmark Definition**

The benchmark measures the performance of accessing object keys versus finding elements in an array or using a Map.

**Test Case 1: Object Access**

* **Script**: `items.forEach(item => objContainer[item.value])`
* **Library/Feature**: None
* **What's being tested**: This test case accesses an object (`objContainer`) by its key. In JavaScript, objects are hash tables that use keys to store and retrieve values.
* **Pros**: Object access is generally fast in modern JavaScript engines because it uses a hash table lookup. This approach is suitable for accessing elements by their unique identifier or key.
* **Cons**: Creating an object with many properties can be memory-intensive.

**Test Case 2: Map Access**

* **Script**: `items.forEach(item => mapContainer.get(item.value))`
* **Library/Feature**: None
* **What's being tested**: This test case uses a Map (`mapContainer`) to store and retrieve elements by their value. Maps are similar to objects but are designed for storing key-value pairs.
* **Pros**: Maps are optimized for fast lookup, insertion, and deletion of elements by their unique identifier or key.
* **Cons**: Creating a large Map can be memory-intensive.

**Test Case 3: Array Find**

* **Script**: `items.forEach(item => arrContainer.find(containerItem => containerItem.value === item.value))`
* **Library/Feature**: None
* **What's being tested**: This test case uses the `find()` method to search for an element in an array (`arrContainer`) by its value.
* **Pros**: Array find is a simple and intuitive approach, but it has some performance overhead due to the need to iterate over the entire array.
* **Cons**: Array find can be slow if the array is large or if many elements are being searched.

**Benchmark Results**

The results show that:

* Accessing an object by its key (`"object"` test) is the fastest approach, with approximately 22.7k executions per second.
* Using a Map (`"map"` test) is slower than accessing an object but still relatively fast, with about 12.1k executions per second.
* Searching for an element in an array using `find()` (`"array"` test) is the slowest approach, with approximately 1.5k executions per second.

**Other Alternatives**

If you need to access elements by their value and don't mind the overhead of creating a Map or searching an array, consider using:

* A `Set` for fast lookup and removal of unique values.
* An object with a more complex key structure (e.g., nested objects) if you need to store and retrieve hierarchical data.

Remember that the best approach depends on your specific use case and requirements. If you're looking for high-performance access by value, using an object or a Map might be the way to go.

Related benchmarks:

Object key access vs array finds (version: 0)

Comparing performance of: object vs map vs array

Created: 3 years ago by: Guest

Jump to the latest result

object

map

array

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

No previous run results

Autogenerated LLM Summary (model llama3.1:latest, generated one year ago):