Benchmark: OOP-ish SoA vs AoS

OOP-ish SoA vs AoS (version: 1)

Same as usual Float Array base SoA vs AoS but with classes and objects instead of raw number. I was cursious if the benefit of SoA still holds true even with classes. Same as https://www.measurethat.net/Benchmarks/Show/1909/0/soa-vs-aos but with classes. And some window hackery to get around dated benchmarking suite...

Comparing performance of: SoA vs AoS

Created: one month ago by: Guest

Jump to the latest result

Script Preparation code:

'use strict';
window.N = 1000000;

class PointAndVelocity {
    constructor(x, y, vx, vy) {
        this.x = x;
        this.y = y;
        this.vx = vx;
        this.vy = vy;
    }
}

class Point {
    constructor(x, y) {
        this.x = x;
        this.y = y;
    }
}

class Velocity {
    constructor(vx, vy) {
        this.vx = vx;
        this.vy = vy;
    }
}

aos = Array(N).fill(new PointAndVelocity(0, 0, 0, 0))
    .map(() => new PointAndVelocity(Math.random() * 100|0, Math.random() * 100|0, Math.random() * 100|0, Math.random() * 100|0));

// SoA, we try to duplicate the data so numeric differences are out of the question.
points = Array(N).fill(new Point(0, 0)).
    .map((_, i) => new Point(aos[i].x, aos[i].y));
velocities = Array(N).fill(new Velocity(0, 0)).
    .map((_, i) => new Velocity(aos[i].vx, aos[i].vy));

Tests:

SoA
var N = window.N; for (var i = 0; i < N; ++i) { var point = points[i]; var velocity = velocities[i]; point.x += velocity.vx; point.y += velocity.vy; }
AoS
var N = window.N; for (var i = 0; i < N; ++i) { var pav = aos[i] pav.x += pav.vx; pav.y += pav.vy; }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
SoA
AoS

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 25 days ago)

User agent: Mozilla/5.0 (Linux; arm_64; Android 13; TFY-LX1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.6834.97 YaBrowser/25.2.8.97.00 SA/3 Mobile Safari/537.36

Browser/OS: Yandex Browser 25 on Android

View result in a separate tab

Test name	Executions per second
SoA	1093798.5 Ops/sec
AoS	1097718.6 Ops/sec

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

LLMs can make mistakes. Check important info.

This benchmark compares two data organization strategies in JavaScript: **Structure of Arrays (SoA)** and **Array of Structures (AoS)**, in the context of object-oriented programming (OOP) using classes. The benchmark demonstrates how each approach performs when manipulating point and velocity data.

### Explanation of the Benchmark

1. **Data Structures:**
   - **PointAndVelocity (AoS)**: This class encapsulates both position (x, y) and velocity (vx, vy) information in a single object. The process tests how operations on these combined objects perform.
   - **Point (SoA)**: This class encapsulates only the position data.
   - **Velocity (SoA)**: This class encapsulates only the velocity data.

The benchmark creates two different data setups:
   - **AoS Setup**: An array (`aos`) is created where each element is an instance of the `PointAndVelocity` class. Manipulations happen on these objects directly.
   - **SoA Setup**: Two separate arrays (`points` and `velocities`) are created for position and velocity data, respectively.

2. **Test cases:**
   - **SoA Test**: Iterates through the `points` and `velocities` arrays. Each point's position is updated based on its corresponding velocity, allowing performance comparisons of separate arrays for organizing eigenvalues.
   - **AoS Test**: Iterates through the `aos` array, updating the position of each point using velocity stored in the same object.

### Pros and Cons of Each Approach

#### Array of Structures (AoS)
**Pros:**
- Simplicity: Each entity (point and its velocity) is encapsulated in one object, making it intuitive to manage related data.
- Better encapsulation: Reduces the chance of mismatching velocities or points since they reside together.

**Cons:**
- Cache inefficiency: When updating properties, the data in memory may not be contiguous, potentially leading to cache misses, which can slow down overall performance, especially for large datasets.
- Structural rigidity: Changes to data structure may require changes throughout the codebase.

#### Structure of Arrays (SoA)
**Pros:**
- Cache performance: By storing related properties of data separately and contiguously, memory accesses become more efficient, which is especially beneficial for large datasets.
- Flexibility: Each type of data can be manipulated independently, allowing more complex operations or optimizations on one aspect without impacting others.

**Cons:**
- Complexity: Requires careful management of indices to ensure that data remains synchronized (i.e., ensuring that each element in the `points` array correctly corresponds to the element in the `velocities` array).
- More verbose: Increased boilerplate to manage multiple arrays representing a single logical entity.

### Performance Considerations
The benchmark results show that both approaches yield quite similar performance, with **SoA** slightly outperforming **AoS**. This may indicate that for this size of data (1,000,000 points), the benefits of caching in SoA can provide a slight performance advantage, despite the overhead from managing multiple arrays.

### Conclusion
In summary, this benchmark illustrates the performance trade-offs between SoA and AoS patterns when implementing object-oriented designs. Developers may choose SoA for scenarios involving numerical computations on large datasets to leverage cache-friendly memory access patterns. In contrast, AoS may be preferred for smaller datasets or when data coherence and ease of use are prioritized over raw performance.

This benchmark serves as a useful reference for software engineers in understanding the implications of their data structures on performance at scale.

Related benchmarks: