Benchmark: for with saved length vs evaluation on every loop cycle

Script Preparation code:

var arr = [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99]

Tests:

With saved length
for (let i = 0, length = arr.length; i < length; i++) arr[i] * arr[i]
Evaluating length on every loop cycle
for (let i = 0; i < arr.length; i++) arr[i] * arr[i]

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
With saved length
Evaluating length on every loop cycle

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 provided JSON and explain what's being tested.

**Benchmark Definition**

The benchmark definition represents two test cases that compare the performance of two approaches in a JavaScript `for` loop:

1. **With saved length**: In this approach, the length of the array is stored in a variable before the loop starts.
2. **Evaluating length on every loop cycle**: In this approach, the length of the array is evaluated inside the loop using the `length` property of the array.

**Comparison**

The benchmark aims to compare the performance of these two approaches. The test case "With saved length" uses a variable to store the length of the array before the loop starts, while the test case "Evaluating length on every loop cycle" evaluates the length of the array inside the loop.

**Pros and Cons**

* **Approach 1: With saved length**
	+ Pros:
		- Reduces the number of times the `length` property is accessed.
		- Can be faster because it avoids the overhead of accessing a property on an object.
	+ Cons:
		- Requires extra memory to store the length variable.
* **Approach 2: Evaluating length on every loop cycle**
	+ Pros:
		- Does not require extra memory to store the length variable.
	+ Cons:
		- Accesses the `length` property more frequently, which can be slower.

**Library and Special JS Feature**

There is no library used in this benchmark. However, it's worth noting that the use of a variable to store the length of the array (`let i = 0, length = arr.length;`) does not require any special JavaScript features beyond basic syntax.

**Other Alternatives**

Some alternative approaches could be:

* Using `const` instead of `var` for the loop variable and stored length variable.
* Using a different data structure, such as an array buffer or a typed array, to reduce memory allocation and deallocation overhead.
* Optimizing the loop itself using techniques like loop unrolling or SIMD instructions.

**Benchmark Preparation Code**

The script preparation code includes:
```javascript
var arr = [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99];
```
The HTML preparation code is empty.

**Individual Test Cases**

Each test case includes a `Benchmark Definition` string that represents the JavaScript code to be executed. The first test case uses the "With saved length" approach, while the second test case uses the "Evaluating length on every loop cycle" approach.

Note that the raw UA string and browser information are not relevant to understanding the benchmark itself.

Latest run results:

Run details: (Test run date: 4 years ago)

User agent: Mozilla/5.0 (Linux; Android 9; Mi 9T Build/PKQ1.190302.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/78.0.3904.96 Mobile Safari/537.36

Browser/OS: Chrome Mobile 78 on Android

View result in a separate tab

Test name	Executions per second
With saved length	33035.8 Ops/sec
Evaluating length on every loop cycle	22080.6 Ops/sec

Related benchmarks:

for with saved length vs evaluation on every loop cycle (version: 0)

Comparing performance of: With saved length vs Evaluating length on every loop cycle

Created: 4 years ago by: Registered User

Jump to the latest result

With saved length

Evaluating length on every loop cycle

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):