Benchmark: Immer & Immutable benchmarks with inceremntal data

HTML Preparation code:

<script src="https://cdnjs.cloudflare.com/ajax/libs/immer/9.0.17/immer.umd.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/immutable/4.2.2/immutable.min.js"></script>

Script Preparation code:

var INITIAL_DATA = { items: {}, count: 0, keys: [] }
var produce = immer.default

var iterationTop = 30;
var iterationBottom = 70;
var iterationFull = iterationTop * iterationBottom;

Tests:

immer many shorts updates
let data = INITIAL_DATA; for (i = 0; i < iterationFull; i++) { data = produce(data, draft => { draft.items[i] = { id: i, name: `NEW-ITEM${i}`, value: i } draft.counter++ draft.keys.push(`NEW-ITEM${i}`) }) }
immer one big update
let data = INITIAL_DATA; data = produce(data, draft => { for (i = 0; i < iterationFull; i++) { draft.items[i] = { id: i, name: `NEW-ITEM${i}`, value: i } draft.counter++ draft.keys.push(`NEW-ITEM${i}`) } })
immer balanced data change
let data = INITIAL_DATA; for (i = 0; i < iterationTop; i++) { data = produce(data, draft => { for (x = 0; x < iterationBottom; x++) { const id = `${i}-${x}` draft.items[id] = { id: id, name: `NEW-ITEM${id}`, value: id } draft.count++ draft.keys.push(`NEW-ITEM${id}`) } }) }
immutable
let immData = Immutable.Record({ items: Immutable.Map({}), count: 0, keys: Immutable.List([]) })(); for (i = 0; i < iterationFull; i++) { immData = immData.update("items", (items) => { return items.set( i, Immutable.Record({ id: i, name: `NEW-ITEM${i}`, value: i })() ); }); immData = immData.set("count", immData.get("count") + 1); immData = immData.update("keys", (keys) => keys.push(`NEW-ITEM${i}`)); }
immutable balanced data change
let immData = Immutable.Record({ items: Immutable.Map({}), count: 0, keys: Immutable.List([]) })(); for (i = 0; i < iterationTop; i++) { immData = immData.update("items", (items) => { let immItems = items; for (x = 0; x < iterationBottom; x++) { const id = `${i}-${x}`; immItems = immItems.set( id, Immutable.Record({ id: id, name: `NEW-ITEM${id}`, value: id })() ); return immItems; } }); } for (i = 0; i < iterationFull; i++) { immData = immData.set("count", immData.get("count") + 1); immData = immData.update("keys", (keys) => keys.push(`NEW-ITEM${i}`)); }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
immer many shorts updates
immer one big update
immer balanced data change
immutable
immutable balanced data change

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gemma2:9b, generated 28 days ago):

LLMs can make mistakes. Check important info.

The benchmark results show the performance of different JavaScript code snippets for updating immutable data structures.  Let's break down what we see:

**Key Observations:**

* **Immutable Libraries:** The tests compare various approaches to updating immutable data, including Immer and raw Immutable.js operations. 
* **Benchmark Metrics:** "ExecutionsPerSecond" indicates how many times each code snippet successfully completes its update operation within a second. Higher values mean faster performance.
* **Performance Variations:** There's significant variation in performance across different scenarios:
    *  **`immutable balanced data change`**: Achieves the highest execution rate (722.38), suggesting efficient updates for well-structured immutable data.
    *  **`immer one big update`**:  Significantly slower than `immutable balanced data change` (256.26) despite using Immer, which aims to optimize these operations. This might indicate limitations of Immer when dealing with large updates.

* **Other Scenarios:** The remaining tests (`immutable`, `immer balanced data change`, and `immer many shorts updates`) have lower execution rates, highlighting the importance of code structure and update patterns for performance.

**Possible Explanations:**

1. **Code Complexity:**  Simpler structures and operations (like `immutable balanced data change`) likely execute faster due to fewer nested operations and less overhead.
2. **Library Implementations:** There might be underlying differences in how Immer and Immutable.js handle updates, leading to variations in efficiency depending on the scenario.

3. **Data Size:**  The `immer one big update` scenario involves a larger update, potentially causing performance bottlenecks regardless of the library used.

**Recommendations:**

*  **Analyze Code Structure:** Carefully examine your data structures and update patterns. Aim for simpler structures and operations whenever possible.
* **Benchmark Different Libraries/Techniques:** Don't rely solely on benchmarks; consider other factors like ease of use, developer experience, and support for specific use cases.

Let me know if you have more questions or want to explore a particular aspect of the benchmark results in more detail!

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/108.0.0.0 Safari/537.36

Browser/OS: Chrome 108 on Windows

View result in a separate tab

Test name	Executions per second
immer many shorts updates	1.1 Ops/sec
immer one big update	256.3 Ops/sec
immer balanced data change	26.8 Ops/sec
immutable	96.4 Ops/sec
immutable balanced data change	722.4 Ops/sec

Related benchmarks:

Immer & Immutable benchmarks with inceremntal data (version: 0)

Comparing performance of: immer many shorts updates vs immer one big update vs immer balanced data change vs immutable vs immutable balanced data change

Created: one year ago by: Registered User

Jump to the latest result

immer many shorts updates

immer one big update

immer balanced data change

immutable

immutable balanced data change

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gemma2:9b, generated 28 days ago):