Benchmark: soa vs aos using Float32Array 2

Script Preparation code:

var x = new Float32Array(1000000),
    y = new Float32Array(1000000),
    z = new Float32Array(1000000);

var vectors = [];
for (var i = 0; i < 1000000; i++) {
    x[i] = Math.random() * 100;
    y[i] = Math.random() * 100;
    z[i] = Math.random() * 100;

    vectors[i] = {
        x: x[i],
        y: y[i],
        z: z[i]
    };
}
var vector;

Tests:

soa
for (var i = 0, li=x.length; i < li; ++i) { x[i] = 2 * x[i]; y[i] = 2 * y[i]; z[i] = 2 * z[i]; }
aos
for (var i = 0, li=vectors.length; i < li; ++i) { vector = vectors[i]; vector.x = 2 * vector.x; vector.y = 2 * vector.y; vector.z = 2 * vector.z; }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
soa
aos

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

**What is being tested?**

The provided benchmark tests the performance difference between two approaches to iterating over data in JavaScript:

1. **Sequential Access (SOA)**: This approach iterates directly over an array using its `length` property, accessing each element by index (`x[i]`, `y[i]`, `z[i]`). The loop variable `i` is incremented manually.
2. **Array Object Access (AOA)**: This approach uses the `for...in` loop to iterate over an array's indices and then accesses each element through the array object itself (`vectors[i]`, `vector.x`, `vector.y`, `vector.z`). The loop variable is still `i`.

**Options compared**

The two approaches differ in how they access and manipulate elements within the arrays:

1. **SOA (Sequential Access)**
	* Pros:
		+ Typically faster, as it avoids object lookup and iteration over indices.
		+ Can be more cache-friendly due to direct access.
	* Cons:
		+ May require manual increment of `i`, which can lead to off-by-one errors or other issues if not managed carefully.
2. **AOA (Array Object Access)**
	* Pros:
		+ Easier to manage iteration and bounds checking, as the loop variable is handled automatically by the `for...in` loop.
		+ Can be more readable, as the intent of accessing elements through the array object is clearer.
	* Cons:
		+ Typically slower due to object lookup and iteration over indices.
		+ May incur higher cache misses due to indirect access.

**Library usage**

None of the provided benchmark definitions use a specific JavaScript library. However, the `Float32Array` data structure is used, which is part of the JavaScript standard library (ECMAScript).

**Special JS features or syntax**

The benchmarks utilize the following special feature:

* **For...in loops**: Instead of using traditional `for` loops with `let i = 0;`, these benchmarks use `for...in` loops to iterate over array indices. This can lead to unexpected behavior if not used carefully, as it may access properties that are not intended to be iterated.

**Other alternatives**

Alternative approaches to iterating over arrays in JavaScript include:

* **Using traditional for loops with incrementing index**: `for (var i = 0; i < array.length; i++)`
* **Using Array.prototype.forEach() or Array.prototype.map()**: These methods provide a more concise and readable way to iterate over arrays, but may incur additional overhead due to the use of these functions.
* **Using typed arrays with iterator protocols**: For performance-critical applications, using typed arrays like `Float32Array` with custom iterator protocols can offer better performance than traditional array iteration.

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0

Browser/OS: Firefox 100 on Mac OS X 10.15

View result in a separate tab

Test name	Executions per second
soa	629.7 Ops/sec
aos	257.1 Ops/sec

Related benchmarks:

soa vs aos using Float32Array 2 (version: 0)

As titled

Comparing performance of: soa vs aos

Created: 2 years ago by: Guest

Jump to the latest result

soa

aos

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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