Benchmark: Test lodash get vs custom get

HTML Preparation code:

<script src='https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.5/lodash.min.js'></script>

Script Preparation code:

function getValueAt(object, path) {
  const pathParts = path.split('.');

  return pathParts.reduce((agg, item) => agg && agg[item], object);
}

var data = {prop1: { prop2: { value: 'abc'}}}

Tests:

_.orderBy
_.get(data, 'prop1.prop2.value');
custom
getValueAt(data, 'prop1.prop2.value');

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
_.orderBy
custom

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

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

**Benchmark Definition**

The benchmark is comparing two approaches to access nested properties in an object: using the `lodash` library (`_`) and a custom implementation (`getValueAt` function).

**Custom Implementation (getValueAt)**

The `getValueAt` function takes two arguments: `object` and `path`. It splits the `path` into individual parts using the dot (`.`) as a separator. Then, it uses the `reduce` method to iterate through each part of the path, starting from the root object. For each part, it checks if the current object has that property (using the existence operator `&&`) and if so, returns the value of that property.

**Lodash Implementation (_get)**

The benchmark defines a separate JavaScript file that imports the `lodash` library (`https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.5/lodash.min.js`). The `_get` function is then used to access the nested properties in the same object as before.

**What's being tested**

The benchmark is testing which implementation is faster:

1. Using the `lodash` library (`_.get`)
2. A custom implementation (`getValueAt`)

**Pros and Cons of Each Approach**

**Lodash Implementation (_get)**

Pros:

* Well-maintained and widely used library
* Efficient implementation for accessing nested properties

Cons:

* Adds an external dependency (the `lodash` library)
* May not be optimized for performance in all cases

**Custom Implementation (getValueAt)**

Pros:

* No external dependencies, reducing the attack surface
* Can be optimized for specific use cases or performance-critical paths

Cons:

* Requires more manual effort to implement and maintain
* May require additional libraries or utilities to support nested property access

**Other Considerations**

* The benchmark uses a simple object with two levels of nesting (`data.prop1.prop2.value`). This may not be representative of real-world scenarios, which can have much deeper and more complex nested structures.
* The `getValueAt` function assumes that the object has the exact same structure as the example object. If this is not guaranteed, additional error handling or fallbacks would be needed.

**Special JS Features/Syntax**

None are explicitly mentioned in this benchmark.

**Alternatives**

Other alternatives for accessing nested properties in JavaScript include:

* Using `ObjectAccessor` libraries like `fast-async-object-accessor` or `object- accessor`
* Implementing a custom recursive function to traverse the object
* Using a library like `es6.object.values` to access object values

Keep in mind that these alternatives may have their own trade-offs and considerations, depending on the specific use case and requirements.

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 OPR/103.0.0.0

Browser/OS: Opera 103 on Windows

View result in a separate tab

Test name	Executions per second
_.orderBy	2668554.2 Ops/sec
custom	4612305.5 Ops/sec

Related benchmarks:

Test lodash get vs custom get (version: 0)

test between lodash getand custom

Comparing performance of: _.orderBy vs custom

Created: one year ago by: Guest

Jump to the latest result

_.orderBy

custom

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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