Benchmark: creating new object vs changing fields

Script Preparation code:

function throwErr() {
  throw new Error("message");
}

Tests:

new object
(function() { let result = {status: 200, message: "ok"}; try { throwErr(); } catch (error) { result = {status: 400, message: error.message}; } return result; })()
mutate object
(function() { const result = {status: 200, message: "ok"}; try { throwErr(); } catch (error) { result.status = 400; result.message = error.message; } return result; })()

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
new object
mutate object

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 130 on Windows

View result in a separate tab

Test name	Executions per second
new object	269840.7 Ops/sec
mutate object	271827.8 Ops/sec

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

LLMs can make mistakes. Check important info.

The benchmark defined here tests two different approaches to handling errors in JavaScript, specifically focusing on how they affect performance: creating a new object versus mutating an existing object.

### Test Cases Overview

1. **New Object Creation**: 
   - In this test case, a new object is instantiated whenever an error occurs. Specifically, if an error is thrown, a new result object is created with updated status and message fields.
   - **Benchmark Definition**:
     ```javascript
     (function() {
       let result = {status: 200, message: "ok"};
       try {
         throwErr();
       } catch (error) {
         result = {status: 400, message: error.message};
       }
       return result;
     })()
     ```
   - **Test Name**: "new object"

2. **Object Mutation**:
   - In this scenario, an existing object is modified when handling the error. This means that if an error occurs, rather than creating a new object, the status and message fields of the existing object are simply updated.
   - **Benchmark Definition**:
     ```javascript
     (function() {
       const result = {status: 200, message: "ok"};
       try {
         throwErr();
       } catch (error) {
         result.status = 400;
         result.message = error.message;
       }
       return result;
     })()
     ```
   - **Test Name**: "mutate object"

### Performance Results

- **Executions Per Second**:
  - Mutating an object executed at approximately **271,827.78** times per second.
  - Creating a new object executed at approximately **269,840.69** times per second.

### Pros and Cons

#### Creating New Objects
- **Pros**:
  - Simplicity: The code clearly shows the creation of a new state.
  - Immutability: If the object is only created upon an error, it may lead to safer code, especially in cases of multi-threading or asynchronous execution where the integrity of the object can be maintained.
  
- **Cons**:
  - Performance: This approach can be less efficient in terms of memory allocation and garbage collection, as each error reallocation can lead to the creation of many temporary objects.

#### Object Mutation
- **Pros**:
  - Performance: Generally faster and more memory-efficient since it avoids the overhead of creating a new object and allows for reuse of an existing reference.
  - Less garbage collection overhead since we are not creating trash objects in memory.

- **Cons**:
  - Clarity: It can sometimes be harder to understand that the state has been modified, especially in larger codebases or when working with complex objects.
  - Potential side effects: If multiple parts of the program are referencing the same object, changes can lead to unintended consequences unless thoroughly managed.

### Other Considerations
- **Garbage Collection**: In JavaScript, memory management is primarily done through garbage collection. Too many allocations (like in the new object creation case) can lead to performance issues due to frequent garbage collections.
- **Use Case Suitability**: The choice between these approaches can depend heavily on the application’s specific contexts and requirements. For example, in high-performance scenarios (like game development), mutating objects might be more appropriate, whereas, in functional programming styles, immutability (creating new objects) is preferred.

### Alternatives
Beyond these two approaches, there are a few alternatives one might consider:
1. **Immutable Data Structures**: Libraries like Immutable.js can provide immutable data types, promoting safe states while managing performance overhead with structural sharing.
2. **Proxies**: Using the Proxy API to intercept and redefine object behavior can give you the benefits of both approaches without the overhead of creating new objects or the pitfalls of mutating existing ones.
3. **Functional Approaches**: Using functional programming techniques to handle state, where functions return new states without side effects, might also be suitable based on the requirement and complexity of the codebase.

In conclusion, while this benchmark provides a clear performance comparison between two distinct approaches, the choice of method often depends on the specific needs of the application, readability of code, and performance considerations concerning the JavaScript environment in use.

Related benchmarks:

creating new object vs changing fields (version: 1)

perfomance differences

Comparing performance of: new object vs mutate object

Created: one month ago by: Guest

Jump to the latest result

new object

mutate object

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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