Benchmark: Switch vs object mapping 3

Tests:

object
const mapping = { 0: true, 1: true, 2: true, 3: true, 4: true, 5: true, 6: true, 7: true, 8: true, 9: true, 10: true, }; const foo = mapping[6];
Switch
switch(6) { case 1: return true; case 2: return true; case 3: return true; case 4: return true; case 5: return true; case 6: return true; case 7: return true; case 8: return true; case 9: return true; case 10: return true; default: return 11; }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
object
Switch

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what's being tested, compared, and other considerations.

**Benchmark Definition**

The benchmark is defined as an object with three properties: `Name`, `Description`, and `Script Preparation Code`. However, in this case, all these fields are empty. The benchmark definition is actually embedded within the individual test cases.

**Individual Test Cases**

There are two test cases:

1. **"object"`**

This test case uses a JavaScript object to map numbers to boolean values. Specifically, it creates an object `mapping` with keys from 0 to 10 and assigns `true` to each key. The test then attempts to access the value of key 6 using the syntax `foo = mapping[6];`.

The purpose of this benchmark is to compare the performance of accessing a value in an object using bracket notation (`[]`) versus a lookup table (in this case, the object itself).

**Comparison**

Two approaches are being compared:

a. **Bracket Notation**: The use of square brackets `[]` to access an object's property.
b. **Lookup Table**: Using the object as a lookup table to retrieve values.

The pros and cons of these approaches:

* Bracket notation:
	+ Pros: Simple, readable, and widely supported.
	+ Cons: Can be slower for large objects due to string concatenation or hash table lookups.
* Lookup Table:
	+ Pros: Can be faster for large objects since it's a direct address lookup.
	+ Cons: Less readable, may not work in all browsers, and can lead to memory issues if the object is too large.

**Library**

In this benchmark, there is no external library being used.

**Special JS Features/Syntax**

There are no special JavaScript features or syntax being tested in this benchmark. It's a straightforward comparison of two common ways to access values in an object.

**Other Alternatives**

If you want to explore alternative approaches, consider the following:

* **Array Indexing**: Instead of using an object, you could use an array with numerical indices. This would eliminate the need for bracket notation or lookup tables.
* **Computed Property Names**: You could use computed property names (e.g., `mapping[6 + 1]`) to access values in a way that's similar to bracket notation but potentially faster.

**Benchmark Results**

The latest benchmark results show that Chrome 121, running on a Mac with macOS 10.15.7, executed the object lookup approximately 20.5 million times per second (95790528). The switch statement execution rate is slightly lower, around 18.4 million times per second (93727920).

Keep in mind that these results might vary depending on your specific use case, JavaScript engine, and hardware configuration.

I hope this explanation helps!

Latest run results:

Run details: (Test run date: 9 months 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
object	95790528.0 Ops/sec
Switch	93727920.0 Ops/sec

Related benchmarks:

Switch vs object mapping 3 (version: 0)

Comparing performance of: object vs Switch

Created: 9 months ago by: Guest

Jump to the latest result

object

Switch

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):