Benchmark: Object vs Map lookup with int keys

Script Preparation code:

window.m = new Map();
window.o = {};
for (let i = 0; i < 1000; ++i) {
  window.m.set(i, i);
  window.o[i] = i;
}

Tests:

Map Lookup
for (let i = 0; i < 1000; ++i) { if (window.m.get(i) !== i) { console.log("bad map key"); } }
Object Lookup
for (let i = 0; i < 1000; ++i) { if (window.o[i] !== i) { console.log("bad object key"); } }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Map Lookup
Object Lookup

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one year ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Browser/OS: Firefox 134 on Windows

View result in a separate tab

Test name	Executions per second
Map Lookup	6505.5 Ops/sec
Object Lookup	8242.3 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what's being tested.

**Benchmark Overview**

The benchmark compares the performance of two lookup approaches: object-based (`window.o`) and map-based (`window.m`). The test checks if a value is present in either of these data structures using the `get()` method. The key distinction here is that object keys are integers, while map keys are strings.

**Options Compared**

Two options are being compared:

1. **Object Lookup**: Using an object (`window.o`) to store values with integer keys.
2. **Map Lookup**: Using a map (`window.m`) to store values with string keys.

**Pros and Cons of Each Approach**

*   **Object Lookup**
    *   Pros:
        *   Lightweight: Objects are typically smaller in memory compared to maps, making them a good choice for storing small amounts of data.
        *   Fast lookups: Object property access is generally faster than map key lookup because it's more efficient for the browser's JavaScript engine.
    *   Cons:
        *   Limited scalability: As the number of keys increases, object performance may degrade due to memory allocation and lookup overhead.
*   **Map Lookup**
    *   Pros:
        *   Scalability: Maps are designed to handle large amounts of data and can scale well with an increasing number of keys.
        *   Flexibility: Map keys can be any type (strings, numbers, symbols), making it a versatile choice for various use cases.
    *   Cons:
        *   Heavier: Maps are typically larger in memory compared to objects, which may impact performance in low-memory scenarios.
        *   Slower lookups: Map key lookup is generally slower than object property access because the browser's JavaScript engine needs to perform a hash lookup.

**Library and Special Features**

The test utilizes two standard JavaScript libraries:

*   **Map**: A built-in JavaScript data structure that stores key-value pairs, where each key is unique.
*   **Object**: A built-in JavaScript data structure that stores values with string keys (or symbols).

No special features or syntax are mentioned in the provided benchmark.

**Alternatives**

Other alternatives for storing and looking up values include:

*   **Array**: An array can be used to store a collection of values, but it's not suitable for lookup operations like this benchmark.
*   **Set**: A set is an unordered collection of unique values, making it unsuitable for this specific use case.

In summary, the benchmark compares the performance of object-based and map-based lookups when searching for integer keys in strings. Understanding the pros and cons of each approach can help developers choose the most suitable data structure for their specific use cases.

Related benchmarks:

Object vs Map lookup with int keys (version: 0)

Comparing the performance of lookups in large objects vs large maps when the keys are strings.

Comparing performance of: Map Lookup vs Object Lookup

Created: 2 years ago by: Guest

Jump to the latest result

Map Lookup

Object Lookup

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):