Benchmark: Can JavaScript benefit from the ECS pattern 2?

Can JavaScript benefit from the ECS pattern 2? (version: 1)

JS arrays are weird and (probably?) not memory-contiguous, but just for kicks, let's see what difference there is (if any) between performing the same action on 1,000,000 objects in an object-oriented style (with the method attached to the object) vs an ECS-style (with the behavior separated from the raw data)

Comparing performance of: OO-style vs ECS-style

Created: 18 days ago by: Guest

Jump to the latest result

Script Preparation code:

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
    this.health = 100;
  }

  tick() {
    this.x += 2;
    this.y += 2;
    this.health -= 1;
  }
}

var pointClasses = [];
var pointObjects = [];

for (let i = 0; i < 1000000; i++) {
  pointClasses.push(new Point(0, 0));
  pointObjects.push({ x: 0, y: 0 });
}

​x
 
class Point {  constructor(x, y) {    this.x = x;    this.y = y;    this.health = 100;  }​  tick() {    this.x += 2;    this.y += 2;    this.health -= 1;  }}​var pointClasses = [];var pointObjects = [];​for (let i = 0; i < 1000000; i++) {  pointClasses.push(new Point(0, 0));  pointObjects.push({ x: 0, y: 0 });}

Tests:

OO-style
pointClasses.forEach((point) => { point.tick(); point.tick(); });
pointClasses.forEach((point) => {
point.tick();
point.tick();
});

ECS-style

pointObjects.forEach((point) => {
  point.x += 2;
  point.y += 2;
  point.health -= 1;
  point.x += 2;
  point.y += 2;
  point.health -= 1;
});

 
pointObjects.forEach((point) => {  point.x += 2;  point.y += 2;  point.health -= 1;  point.x += 2;  point.y += 2;  point.health -= 1;});

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
OO-style
ECS-style

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36

Browser/OS: Chrome 134 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
OO-style	446.1 Ops/sec
ECS-style	337.7 Ops/sec

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

This benchmark compares two different programming paradigms for managing and accessing data: Object-Oriented (OO) style and Entity-Component-System (ECS) style. Both styles are applied to perform operations on a set of 1,000,000 objects, which represent points in a 2D space.

Options Compared

Object-Oriented (OO) Style:
- Each point is represented by an instance of the Point class, which contains methods (like tick()) that encapsulate behavior related to the data.
- The benchmark executes the tick() method on each Point object, which modifies its properties (x, y, health).
Entity-Component-System (ECS) Style:
- Points are represented as plain objects in an array. Instead of using methods attached to each object, the operations on the objects are performed directly in the benchmark code using their properties.
- The benchmark explicitly manipulates the properties of each object, updating the coordinates and health directly in the loop.

Performance Results

OO-style achieved approximately 446.1 executions per second.
ECS-style yielded about 337.7 executions per second.

Pros and Cons

Object-Oriented (OO) Style

Pros:

Encapsulation: Methods tied to objects improve organization and can make code more reusable and easier to maintain.
Clarity: Code that interacts with the object through methods can be clearer and more intuitive.

Cons:

Overhead: Each method call introduces some overhead. In scenarios where performance is critical, this may lead to slower execution, especially with a large number of invocations.

ECS-style

Pros:

Performance: By avoiding method calls and directly manipulating properties, ECS can lead to improved raw speed in scenarios where function call overhead is significant.
Simplicity: The structure itself is simpler because there are no class definitions or method encapsulations.

Cons:

Maintainability: As systems grow in complexity, the separation of data and behavior can lead to code that is harder to understand and maintain.
Lack of encapsulation: Common object-oriented features like polymorphism and inheritance are not available, making it harder to implement certain design patterns.

Considerations

Memory Contiguity: The benchmark hints at performance differences based on memory layout patterns. In JavaScript, arrays can be less memory-contiguous than other data structures, affecting speed during iterations.
Use Cases: The choice between these two styles may depend on the specific application requirements, such as performance needs versus ease of maintenance.

Alternatives

Functional Programming: An approach emphasizing immutability and first-class functions. For tasks that can be parallelized, functional style can leverage features such as map, reduce, and filter effectively.
Hybrid Approaches: Some developers use a combination of OO and ECS – leveraging the benefits of both paradigms. For instance, behavior can be grouped into components while still using inheritance for shared characteristics among certain entities.
Other Libraries and Frameworks: Libraries that facilitate ECS patterns, such as cabinet, can help manage the complexity and performance overhead of large-scale applications that are data-driven.

In summary, the benchmark demonstrates the trade-offs between OO and ECS patterns in JavaScript for performance-critical applications. The results advocate for awareness of memory layout and method overhead during design choices in software development.

LLMs can make mistakes. Check important info.

### Options Compared
1. **Object-Oriented (OO) Style:**
   - Each point is represented by an instance of the `Point` class, which contains methods (like `tick()`) that encapsulate behavior related to the data.
   - The benchmark executes the `tick()` method on each `Point` object, which modifies its properties (`x`, `y`, `health`).

2. **Entity-Component-System (ECS) Style:**
   - Points are represented as plain objects in an array. Instead of using methods attached to each object, the operations on the objects are performed directly in the benchmark code using their properties.
   - The benchmark explicitly manipulates the properties of each object, updating the coordinates and health directly in the loop.

### Performance Results
- **OO-style** achieved approximately **446.1 executions per second**.
- **ECS-style** yielded about **337.7 executions per second**.

### Pros and Cons

#### Object-Oriented (OO) Style
**Pros:**
- Encapsulation: Methods tied to objects improve organization and can make code more reusable and easier to maintain.
- Clarity: Code that interacts with the object through methods can be clearer and more intuitive.

**Cons:**
- Overhead: Each method call introduces some overhead. In scenarios where performance is critical, this may lead to slower execution, especially with a large number of invocations.

#### ECS-style
**Pros:**
- Performance: By avoiding method calls and directly manipulating properties, ECS can lead to improved raw speed in scenarios where function call overhead is significant.
- Simplicity: The structure itself is simpler because there are no class definitions or method encapsulations.

**Cons:**
- Maintainability: As systems grow in complexity, the separation of data and behavior can lead to code that is harder to understand and maintain.
- Lack of encapsulation: Common object-oriented features like polymorphism and inheritance are not available, making it harder to implement certain design patterns.

### Considerations
- **Memory Contiguity:** The benchmark hints at performance differences based on memory layout patterns. In JavaScript, arrays can be less memory-contiguous than other data structures, affecting speed during iterations.
- **Use Cases:** The choice between these two styles may depend on the specific application requirements, such as performance needs versus ease of maintenance.

### Alternatives
1. **Functional Programming:** An approach emphasizing immutability and first-class functions. For tasks that can be parallelized, functional style can leverage features such as map, reduce, and filter effectively.
2. **Hybrid Approaches:** Some developers use a combination of OO and ECS – leveraging the benefits of both paradigms. For instance, behavior can be grouped into components while still using inheritance for shared characteristics among certain entities.
3. **Other Libraries and Frameworks:** Libraries that facilitate ECS patterns, such as `cabinet`, can help manage the complexity and performance overhead of large-scale applications that are data-driven.

Related benchmarks: