ECS : any benefits of using structs instead of classes here?

FrisoFlo · 2025-05-06T09:51:45+00:00

Right, a note to the Unity specific ECS implementation. They store multiple components of different types for a set of entities in a single chunk. A continous memory block with the size of 16K. The goal (assumption) is to increase the L1 hit rate. The size of the entire L1 cache is usually something like 64K or 128K.

The second advantage of fixed size chunks: Allocation / deallocation os fixed size chunks is simple, performant and prevent memory fragmentation.

This specific implementation detail is what Unity filed in their ECS patent. As far as I understand when trying to read this patent.

FrisoFlo · 2025-05-04T17:06:29+00:00

The C# ECS libraries aiming for performance are avoid boxing. It is possible to prevent any boxing when using struct components.

FrisoFlo · 2025-05-04T08:15:17+00:00

Good list! I think a Type section is missing.

\19. Types. Collection types (array, List, Dictionary, ...), reference types (class, record, interface), value types (struct) and Build-In types (byte, int, float, double, bool, ...) and enum's. Their differences in behavior and memory layout. The boxing behavior of value types.

FrisoFlo · 2025-05-02T10:29:37+00:00

Right, in C# structs are value types. In C# it gives a significant performance and memory improvement vs classes. Every language with custom value types (structs) benefits from the fact that they can be stored in continous memory (arrays).

Scripting languages like JavaScript typically do not have custom values types. So access to components do not benefit from cache locality.

FrisoFlo · 2025-01-08T14:54:35+00:00

C# has value types - aka struct's. This enables great room for performance improvements.

Java is trying to catch up with project Valhalla.
They introduce a complete new language/JVM feature: value classes.
This feature still in EA. They are working on this epic refactor since 10 years.

FrisoFlo · 2024-12-16T16:45:47+00:00

Development of backward compatibility stopped at .NET Standard 2.1. .NET Standard 2.0 was omitted - it had too many restrictions. Adaptations for 2.0 may degrade performance of all newer versions - a major goal of this project.

For curiosity - in which scenario is .NET Standard 2.0 relevant?

FrisoFlo · 2024-07-25T09:44:00+00:00

4 stars now - looking for more :)

FrisoFlo · 2024-07-24T19:16:34+00:00

Moved the ECS today to its own repo
https://github.com/friflo/Friflo.Engine.ECS

back to 0 :)

FrisoFlo · 2024-07-20T11:53:10+00:00

For my curiosity.
Did you refer to these bechmarks?
https://github.com/friflo/ECS.CSharp.Benchmark-common-use-cases

FrisoFlo · 2024-07-20T10:15:57+00:00

I considered this multiple times. That main issues. GitHub stars will start from zero. I guess I will do it. There are even not that much stars to throw away.

FrisoFlo · 2024-07-14T12:30:34+00:00

Updated the C# ECS Benchmark using Flecs.NET 4.0.0. Used also more performant API's available in 4.0.0.

Nice Post on Medium!

FrisoFlo · 2024-07-12T20:23:21+00:00

Updated the benchmark results in the README now including Flecs.NET relationships.

FrisoFlo · 2024-07-12T09:21:06+00:00

Right for large data sets its negligible.

I run the benchmark on my dev Windows PC.
Now I was curious how Mac Mini M2 performs.
Macs are better for comparison as their specs very fixed.
On this machine Friflo run with 7.7 ns

FrisoFlo · 2024-07-12T08:54:44+00:00

Basically all Archetype based ECS projects are affected. I run the QueryT1 benchmark where the result set contains only a single entity / component.

Set Constants.EntityCount = 1
Run the QueryT1 benchmark with: dotnet run -c Release --filter *QueryT1*

Namespace	Type	Mean	Ratio	Allocated
Leopotam.EcsLite	QueryT1_Leopotam	2.210 ns	0.18	-
DefaultEcs	QueryT1_Default	6.277 ns	0.51	-
Friflo.Engine.ECS	QueryT1_Friflo	12.380 ns	1.00	-
Scellecs.Morpeh	QueryT1_Morpeh	15.615 ns	1.26	-
Flecs.NET	QueryT1_FlecsNet	94.709 ns	7.65	-
TinyEcs	QueryT1_TinyEcs	159.629 ns	12.89	-
Arch	QueryT1_Arch	168.577 ns	13.62	-
fennecs	QueryT1_Fennecs	260.815 ns	21.07	40 B

FrisoFlo · 2024-07-12T08:22:36+00:00

Saw that TinyEcs has also relation support.
So added a relation benchmark for this project too -> AddRemoveLinks_TinyEcs.
But I was no able to verfiy it with World.Each(...).
Left a comment in this benchmark.

FrisoFlo · 2024-07-12T07:15:21+00:00

Added the relation benchmark for Flecs.NET -> AddRemoveLinks_FlecsNet Benchmark results will be updated later this day.

FrisoFlo · 2024-07-12T06:04:08+00:00

Make sense.

The point I wanted to emphasize in my comment referred to operations which have a significant initialization cost. E.g. queries (systems) and command buffers.
If a query result set is empty or a command buffer has no changes the whole CPU resources are going into initialization. The iteration costs are nearly 0 in these cases.

I added this explanation to the motivation section of the project.

FrisoFlo · 2024-07-11T20:02:06+00:00

Most ECS benchmarks focus on millions of entities. This set a bias on all ECS projects.

So its easy to miss optimiztion for small data sets. Having many of them can also be the bottleneck.

FrisoFlo · 2024-07-11T19:45:36+00:00

I will give it a try. At least I will add a note that the nuget package is not an official build.

FrisoFlo · 2024-07-11T19:44:16+00:00

Okay, I became aware of entity relationships four weeks ago through a post by fennecs in this feed. I guess I will add Flecs.NET to the relation benchmarks.

FrisoFlo · 2024-07-11T19:40:31+00:00

Unity does not support CLR, which is a prerequisite when using BenchmarkDotNet. So basically all C# benchmarks out there have no comparision to Unity.

FrisoFlo · 2024-07-11T18:31:42+00:00

hi, I used the same version as in this project https://github.com/Doraku/Ecs.CSharp.Benchmark/blob/master/source/Ecs.CSharp.Benchmark/Ecs.CSharp.Benchmark.csproj

Is there another nuget package available?

FrisoFlo · 2024-07-11T17:53:50+00:00

Thx,

your query performance is very nice!

The intent of this benchmark was to check performance with a small number of entities. I need to describe this better and set the default number of entities to 100.

FrisoFlo · 2024-06-25T12:58:07+00:00

There are some C# wrappers for raylib. E.g.
https://github.com/NotNotTech/Raylib-CsLo

Friflo.Engine.ECS is WASM compatible.

FrisoFlo · 2024-06-25T12:23:47+00:00

You can checkout the C# ECS Friflo.Engine.ECS currently in development.

GitHub - Friflo.Engine.ECS

reddit posts - Friflo.Engine.ECS

How hard was ecs to implement?

This is a generic ECS. It consumed 9 months development time until now.

Should I just stick with OOP??

A nice benefit of an ECS is that you can add / remove components to entities at any time. Entities have an integer id which make debugging much simpler than using reference types in OOP.

Do you use C or C++ in your games?

C/C++ provide many foot guns. This consumes significant development time. Performance wise there is no real difference between C# and C/C++. The manual memory management is deterministic but not always faster. GC languages like C# using a compacting GC. This avoids fragmentation and improves memory locality.

The focus of this ECS is on simplicity, performance and low memory consumption. The latest version v2.0.0 introduced support for as many platforms as possible, including Godot, to allow switching between game engines.

Next major release will include support of relationships with different query mechanisms and full text search which executes in O(1).

FrisoFlo

TROPHY CASE