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: 6 days 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));

​x
 
'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;
}

 
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;
}

 
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

Experimental features:

Memory measurements supported only in Chrome.
For precise memory measurements Chrome must be launched with --enable-precise-memory-info flag.
More information: Monitoring JavaScript Memory

Test case name	Result
SoA
AoS

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36

Browser/OS: Chrome 134 on Windows

View result in a separate tab

Test name	Executions per second
SoA	3521552.0 Ops/sec
AoS	3509384.0 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated 6 days ago):

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

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.
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.

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: