Benchmark: Usporedba 2 - MeasureThat.net

Script Preparation code:

window.bigMap = {};
window.bigArray = Array.from({length: 1000}).map((_, index) => {
  const id = "person-id-" + index;
  const person = { id: id, name: `John Doe ${id}`, age: 18 + Math.floor(Math.random() * 70)  };
  bigMap[id] = person;
  return person
})

Tests:

Find person in map
const id = "person-id-" + Math.floor(Math.random() * 1000); const person = window.bigMap[id];
Find person in array
const id = "person-id-" + Math.floor(Math.random() * 1000); const person = window.bigArray.find(p => p.id === id);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Find person in map
Find person in array

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 2 years ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Browser/OS: Chrome 121 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Find person in map	4264766.0 Ops/sec
Find person in array	399684.0 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks on MeasureThat.net!

**What is tested?**

The benchmark measures two different approaches to find a specific object (person) in an array (`window.bigArray`) or in a map (`window.bigMap`):

1. **Find person in array**: This test case finds a person in the `bigArray` using the `find()` method, which returns the first element that satisfies the provided condition.
2. **Find person in map**: This test case finds a person in the `bigMap` using the object's key (`id`) to access its value.

**Options compared**

The two approaches are compared for performance:

1. **Find person in array**: Using the `find()` method, which iterates through the array until it finds a match.
2. **Find person in map**: Directly accessing the object using its key (`id`), which is assumed to be fast since maps use hash tables.

**Pros and cons of each approach**

1. **Find person in array**:
	* Pros: Simple, straightforward, and easy to understand.
	* Cons: Iteration through the entire array can be slow for large datasets.
2. **Find person in map**:
	* Pros: Fast lookups since maps use hash tables, reducing the time complexity from O(n) to O(1).
	* Cons: Assumes that the `id` key exists in the map, which may not always be the case.

**Other considerations**

In addition to performance, other factors like memory usage and code readability should also be considered when choosing between these approaches. For example, using a map might lead to better cache locality and reduced memory allocation for large datasets.

**Library or framework used**

None are explicitly mentioned in the provided benchmark definition. However, it's worth noting that MeasureThat.net uses a JavaScript runtime environment, which provides an execution context for running benchmarks.

**Special JS features or syntax**

No special features or syntax are used in this benchmark. The code is standard JavaScript, with no ES6+ syntax or specific libraries beyond the built-in `Array` and `Object`.

**Other alternatives**

If you need to measure performance of finding a specific object in an array or map, other approaches might include:

1. **Linear search**: Iterating through the entire array or map to find a match.
2. **Binary search**: A more efficient approach for arrays, which involves dividing the search space in half at each step.
3. **Caching**: Storing frequently accessed data in a cache layer to reduce lookup times.

Keep in mind that these alternatives may have different trade-offs in terms of performance, memory usage, and code complexity.

Related benchmarks:

Usporedba 2 (version: 0)

Comparing performance of: Find person in map vs Find person in array

Created: 2 years ago by: Guest

Jump to the latest result

Find person in map

Find person in array

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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