Benchmark: for-in-hasOwnProperty vs object.keys

Script Preparation code:

var obj = {
  'a': 1,
  'b': 1,
  'c': 1,
  'd': 1,
  'e': 1,
  'f': 1,
  'g': 1
};

Tests:

for-in
for (var i=10000; i > 0; i--) { for (var key in obj) { if(obj.hasOwnProperty(key)) { console.log(key); } } }
Object.keys
for (var i=10000; i > 0; i--) { Object.keys(obj).forEach(key => console.log(key)); }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
for-in
Object.keys

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 4 months ago)

User agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Mobile Safari/537.36

Browser/OS: Chrome Mobile 143 on Android

View result in a separate tab

Test name	Executions per second
for-in	1.1 Ops/sec
Object.keys	0.9 Ops/sec

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

LLMs can make mistakes. Check important info.

**Overview of the Benchmark**

The provided benchmark measures the performance difference between two approaches for iterating over an object's properties: `for-in` and `object.keys`. The test case uses a predefined JavaScript object with 11 properties, all initialized to the value 1.

**Approach Comparison**

There are two approaches being compared:

### 1. `for-in`

This approach uses the `for...in` loop, which iterates over an object's property names in the order they were defined in the object. The `hasOwnProperty()` method is used to filter out properties that may be inherited from the prototype chain.

**Pros:**

* Can handle cases where some properties are inherited from the prototype chain.
* May be more efficient for objects with a large number of properties, since it only iterates over the defined properties.

**Cons:**

* Has a higher overhead due to the use of `hasOwnProperty()`, which involves checking if each property is an own property of the object.
* Can be slower than `object.keys` for simple iteration cases, as it involves additional checks and may lead to more cache misses.

### 2. `object.keys`

This approach uses the `Object.keys()` method, which returns an array of a given object's own enumerable property names.

**Pros:**

* Faster iteration since it only iterates over the defined properties without any additional checks.
* Reduces overhead by avoiding the use of `hasOwnProperty()` and minimizing cache misses.

**Cons:**

* May not work as expected for objects with inherited properties, as these are not included in the returned array.
* Requires a compatible JavaScript engine that supports the `Object.keys()` method (not all older browsers support it).

**Library Usage**

There is no library usage in this benchmark. The test case only uses built-in JavaScript methods and objects.

**Special JS Features or Syntax**

The benchmark does not use any special JavaScript features or syntax. It only relies on standard JavaScript language constructs.

**Alternative Approaches**

Other approaches for iterating over an object's properties might include:

* Using a `forEach()` loop with an iterator function: `for (const key in obj) { obj[key].forEach((value) => console.log(key)); }`
* Utilizing a library like Lodash or Underscore.js, which provides utility functions for working with objects and arrays.

**Other Considerations**

When choosing between these two approaches, consider the following factors:

* Performance: If speed is critical and most properties are defined in the object, `object.keys` might be a better choice.
* Code readability: `for-in` can be more readable when working with simple iteration cases, but may lead to confusion for developers unfamiliar with this syntax.
* Compatibility: Make sure to test on browsers or environments that support the chosen approach.

Related benchmarks:

for-in-hasOwnProperty vs object.keys (version: 0)

Comparing performance of: for-in vs Object.keys

Created: 4 years ago by: Guest

Jump to the latest result

for-in

Object.keys

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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