Benchmark: destructing vs mutating for large objects

Script Preparation code:

var obj = {
        "refEntityId": {
          "entityType": "DEVICE",
          "id": "6c273f20-034a-11f0-88b9-d3b4c2c0424f"
        },
        "refEntityKey": {
          "key": "ALL_ERRORS_COUNT",
          "type": "TS_LATEST"
        },
        "defaultValue": "0"
      }

Tests:

mutating
obj.refEntityId.id = null;
destructing
const result = { ...obj, refEntityId: { ...obj.refEntityId, id: null } };

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
mutating
destructing

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 145 on Windows

View result in a separate tab

Test name	Executions per second
mutating	38940856.0 Ops/sec
destructing	20941396.0 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):

LLMs can make mistakes. Check important info.

The benchmark titled **"destructing vs mutating for large objects"** compares two approaches for modifying a property of a large JavaScript object. The two test cases represented are **"mutating"** and **"destructing."** Here's a breakdown of what’s tested, the options being compared, and their advantages and disadvantages:

### Test Cases

1. **Mutating**:
   - **Test Definition**: `obj.refEntityId.id = null;`
   - **Description**: This approach directly modifies the property `id` of the `refEntityId` object within the main object `obj`. This is an in-place mutation where the existing object is changed.
  
2. **Destructing**:
   - **Test Definition**: `const result = { ...obj, refEntityId: { ...obj.refEntityId, id: null } };`
   - **Description**: This method creates a new object using the spread operator (`...`). It constructs a new object with all properties of `obj` and creates a new `refEntityId` object that has the `id` set to `null`. This approach does not mutate the original object but rather generates a new one.

### Comparison of Approaches

- **Performance**:
  - The results indicate that the mutating approach (`mutating`) is significantly faster, achieving **156,181,104 executions per second**, compared to the destructuring approach (`destructing`), which reached **50,795,684 executions per second**.
  
- **Memory Usage**:
  - The mutating approach is also more memory efficient since it modifies the existing object and does not require additional space for a new object.
  - The destructing approach, on the other hand, generates a new object and can lead to increased memory consumption, especially for large objects with many nested properties.

- **Code Maintainability**:
  - The destructing method enhances immutability, which can make it easier to track changes and understand the state of the application as it avoids side effects from modifying existing objects.
  - The mutating approach can lead to unintended side effects if the mutated object is shared among different parts of the application.

### Conclusion

- **Pros and Cons**:
  - **Mutating**: Pros include faster performance and lower memory usage. Cons include potential side effects from modifying shared state.
  - **Destructing**: Pros involve improved readability, maintainability, and avoiding side effects. Cons relate to slower performance and higher memory usage due to object copying.

### Alternatives

Other alternatives for modifying object properties include:

- **Functional Programming Approaches**: Libraries like **Immutable.js** provide structures for immutable data that offer performance optimizations within the functional programming paradigm.
  
- **Object.assign()**: Instead of using the spread operator for creating new object copies, `Object.assign()` can achieve similar results without launching a new object instance.

- **Lodash**: This utility library has functions like `_.cloneDeep()` for performing deep cloning, albeit at some performance costs.

Choosing between these approaches depends on the use case, the size of data being manipulated, and the architectural decisions regarding immutability and performance requirements within an application.

Related benchmarks:

destructing vs mutating for large objects (version: 1)

destructing vs mutating for large objects

Comparing performance of: mutating vs destructing

Created: one year ago by: Guest

Jump to the latest result

mutating

destructing

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):