Benchmark: Map keyed by String or Number

Map keyed by String or Number (version: 1)

Comparing different methods of looking up values keyed by a mixture of string and number keys, for a small number of entries. Used to make decisions about how to cache reverse enum key lookups in ts-enum-util: https://github.com/UselessPickles/ts-enum-util

Comparing performance of: Polyfill Map by Value vs Native Map by Value vs Native Map by String vs Object by String

Created: 8 years ago by: Registered User

Jump to the latest result

Script Preparation code:

function SlowMap() {
  this._keys = [];
  this._values = [];
}

SlowMap.prototype = {
  set: function(key, value) {
    const index = this._keys.indexOf(key);
    if (index !== -1) {
      this._values[index] = value;
    } else {
      this._keys.push(key);
      this._values.push(value);
    }
  },
  
  get: function(key) {
    const index = this._keys.indexOf(key);
    if (index !== -1) {
      return this._values[index];
    } else {
      return undefined;
    }
  }
};

var VALUE_COUNT = 10;
var VALUES = [];

var slowMapByValue = new SlowMap();
var nativeMapByValue = new Map();
var nativeMapByString = new Map();
var objectMapByString = {};

function createStringKey(value) {
  // Need to include type info in key to avoid collisions between similar string and number values.
  return (typeof value) + value;
}

for (let i = 0; i < VALUE_COUNT; ++i) {
  var value = (i % 2) ? i : "value_" + i;
  
  VALUES.push(value);
  slowMapByValue.set(value, i);
  nativeMapByValue.set(value, i);
  nativeMapByString.set(createStringKey(value), i);
  objectMapByString[createStringKey(value)] = i;
}

var testLoopCount = 0;

Tests:

Polyfill Map by Value
const result = slowMapByValue.get(VALUES[testLoopCount++ % VALUE_COUNT]);
Native Map by Value
const result = nativeMapByValue.get(VALUES[testLoopCount++ % VALUE_COUNT]);
Native Map by String
const result = nativeMapByString.get(createStringKey(VALUES[testLoopCount++ % VALUE_COUNT]));
Object by String
const result = objectMapByString[createStringKey(VALUES[testLoopCount++ % VALUE_COUNT])]

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Polyfill Map by Value
Native Map by Value
Native Map by String
Object by String

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.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down the test case and explain what's being tested.

**Benchmark Definition**

The benchmark is designed to compare different approaches for looking up values in a data structure. In this case, we have four options:

1. `SlowMapByValue`: A custom implementation of a map (dictionary) that uses an array-based lookup.
2. `NativeMapByValue`: The built-in `Map` object in JavaScript, which is optimized for fast lookups.
3. `NativeMapByString`: Another built-in JavaScript object, `Map`, but this time using strings as keys instead of values.
4. `ObjectByString`: A custom implementation that uses an object with string keys to store values.

**Options being compared**

The benchmark compares the performance of these four options in terms of how fast they can look up a value by its key. The test cases use a small dataset (10 entries) and iterate over it, accessing each entry using the `get` method.

**Pros and Cons**

Here's a brief summary of the pros and cons of each option:

1. **SlowMapByValue**: This implementation has a slower lookup time compared to the built-in map objects. However, it's useful for demonstrating how a custom implementation can be done.
2. **NativeMapByValue**: The built-in `Map` object is optimized for fast lookups and is generally the best choice for this type of operation.
3. **NativeMapByString**: Using strings as keys can lead to slower performance due to the overhead of string comparison and hashing.
4. **ObjectByString**: This implementation is similar to `NativeMapByString`, but it doesn't use a built-in object, which might be beneficial for small datasets.

**Other considerations**

* **Type safety**: The `SlowMapByValue` implementation includes type information in the key to avoid collisions between similar string and number values. This adds overhead but ensures that the map is type-safe.
* **Memory usage**: The custom implementations (`SlowMapByValue`, `ObjectByString`) likely have higher memory usage compared to the built-in objects.

**Library usage**

None of the test cases use any external libraries beyond the standard JavaScript library (ECMAScript).

**Special JS features or syntax**

The benchmark doesn't use any special JavaScript features or syntax. It's a straightforward implementation of map-like data structures and lookups.

**Alternatives**

If you wanted to compare these options, you could also consider using other approaches, such as:

* Using a `Set` object instead of a map
* Implementing a custom hash table
* Using a library like Lodash or Ramda for functional programming
* Comparing performance using tools like Benchmark.js or jsperf

Related benchmarks: