Benchmark: Delete vs undefined vs spread

Script Preparation code:

var obj = {
  a:1,
  b:2,
  c:3
}

Tests:

delete
delete obj.a
spread
const { a, ...rest } = obj;
undefined
obj.a = undefined

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
delete
spread
undefined

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36

Browser/OS: Chrome 114 on Linux

View result in a separate tab

Test name	Executions per second
delete	14757653.0 Ops/sec
spread	1143304.9 Ops/sec
undefined	4514339.0 Ops/sec

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

LLMs can make mistakes. Check important info.

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

**Benchmark Definition**

The benchmark definition is a JSON object that provides metadata about the benchmark. In this case, the benchmark is named "Delete vs undefined vs spread". The description field is empty, which means there isn't any detailed explanation of what the benchmark aims to measure. The script preparation code is provided as JavaScript code that creates an object `obj` with three properties: `a`, `b`, and `c`. This suggests that the benchmark will be measuring how fast different approaches delete or manipulate the values of these properties.

**Test Cases**

There are three individual test cases:

1. **delete**: This test case measures the performance of deleting a property (`delete obj.a`) on the created object.
2. **spread**: This test case measures the performance of using the spread operator (`const { a, ...rest } = obj;`) to extract a subset of properties from the object.
3. **undefined**: This test case measures the performance of assigning `undefined` to a property (`obj.a = undefined;`) on the created object.

**Options Compared**

The benchmark is comparing three different approaches:

* Deleting a property using the `delete` operator
* Using the spread operator to extract a subset of properties
* Assigning `undefined` to a property

**Pros and Cons of Each Approach**

Here's a brief overview of each approach:

1. **Delete Operator (`delete`)**:
	* Pros: Simple, efficient, and widely supported.
	* Cons: Can be slower due to the need to create an internal lookup table to track deleted properties.
2. **Spread Operator (`const { a, ...rest } = obj;`)**:
	* Pros: Efficient and concise way to extract subset of properties. Reduces memory allocation and deallocation overhead.
	* Cons: May require additional memory allocations due to the creation of new variables `a` and `rest`. Can be slower for very large objects.
3. **Assigning `undefined`**:
	* Pros: Simple and widely supported, as it's a basic assignment operation.
	* Cons: Can lead to property duplication issues if not used carefully. May incur additional memory allocation overhead.

**Library and Special JavaScript Features**

None of the test cases use any external libraries or special JavaScript features like async/await, generators, or Web Workers.

**Other Alternatives**

Some alternative approaches that could be explored for deletion and manipulation of object properties include:

* Using `Object.delete()` (available in modern browsers) instead of the `delete` operator.
* Implementing a custom "weak reference" data structure to track deleted properties.
* Using a more advanced technique like "property caching" to reduce memory allocations.

Keep in mind that these alternatives may come with their own trade-offs and performance implications, which might not be directly comparable to the approaches tested in this benchmark.

Related benchmarks:

Delete vs undefined vs spread (version: 0)

Comparing performance of: delete vs spread vs undefined

Created: one year ago by: Guest

Jump to the latest result

delete

spread

undefined

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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