Faster to replace the entire component than to update fields - expected?

[Stovoy]

I was very surprised by this behavior! Trying to squeeze out every bit of performance I can, and I discovered this:

public class MovementSystem : BaseSystem<World, float> {
    public MovementSystem(World world) : base(world) { }

    private readonly QueryDescription movingQuery =
        new QueryDescription().WithAll<Position, Angle, Speed>();

    public override void Update(in float deltaTime) {
        World.Query(in movingQuery,
            (ref Position position, ref Angle angle, ref Speed speed) => {
                // Method A: Runs in ~2.5ms (60,000 entities)
                position.X += (float) Math.Cos(angle.Value) * speed.Value;
                position.Y += (float) Math.Cos(angle.Value) * speed.Value;

                // Method B: Runs in ~1.8ms (60,000 entities)
                position = new Position {
                     X = position.X + (float) Math.Cos(angle.Value) * speed.Value,
                     Y = position.Y + (float) Math.Sin(angle.Value) * speed.Value
                };
            });
    }
}

This is a .NET 7 standalone CLI build, running in release mode with code optimizations, (Windows/Rider). I was surprised that this is more efficient. Is this expected? If so, perhaps it should be included in Performance Tips, as the current similar examples demonstrate updating the fields separately.

[genaray]

I was very surprised by this behavior! Trying to squeeze out every bit of performance I can, and I discovered this:

public class MovementSystem : BaseSystem<World, float> {
    public MovementSystem(World world) : base(world) { }

    private readonly QueryDescription movingQuery =
        new QueryDescription().WithAll<Position, Angle, Speed>();

    public override void Update(in float deltaTime) {
        World.Query(in movingQuery,
            (ref Position position, ref Angle angle, ref Speed speed) => {
                // Method A: Runs in ~2.5ms (60,000 entities)
                position.X += (float) Math.Cos(angle.Value) * speed.Value;
                position.Y += (float) Math.Cos(angle.Value) * speed.Value;

                // Method B: Runs in ~1.8ms (60,000 entities)
                position = new Position {
                     X = position.X + (float) Math.Cos(angle.Value) * speed.Value,
                     Y = position.Y + (float) Math.Sin(angle.Value) * speed.Value
                };
            });
    }
}

This is a .NET 7 standalone CLI build, running in release mode with code optimizations, (Windows/Rider). I was surprised that this is more efficient. Is this expected? If so, perhaps it should be included in Performance Tips, as the current similar examples demonstrate updating the fields separately.

This is really very very interesting... and in a way it doesn't make sense.

The first thing that strikes me is that it is C# specific and probably has nothing to do with the ECS. That makes it even more interesting.

The update of single fields should be more efficient in every programming language. Replacing fields needs an additional constructor which should make the whole thing slower :0

I am indeed a bit confused by this, maybe you should have a look at the IL code / assembly code ^^
Im gonna investigate this later when I'm home :)

[genaray]

I discovered this:

Did some research and checked the IL in sharplab :
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBLANgHwAEAmARgFgAoKwgZgAIBnDKAVzA3oAUJHsNsEAHYBvenXoAzXBACGnBAG5xDaXM4BPZQF9FVGgxL0AwvRFV6l+has8+A4U1YAHGFDt7KV616sTCKPQAsgAUAJRmNt6WUdGMLm529AC89EIwAO7cvPyCovQIKU6u7rwAdAgA1JVo9BpF8SV2ZRrV9Lqx3rHasbH+gQAqMMzh5r7RxYnlhZWpjVOMFZ4TlvOli/Wzk+sty1Y9lNpAA=

Asigning the attributes directly produces less IL and assembly code.
So it should be faster actually :o

A benchmark could solve this question once and for all ^^

[Stovoy]

Didn't know about Shapelab! I played around with it and got a version that produces about as much IL for new position: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBLANgHwAEBmAAgGcMoBXMDUgBQnOw2wgDtSBvUgWABQpYaRKkAZrggBDeggDc/ISLGSZ9AJ6LBAX3mDBYwgCZSAFRiUAylVoYAshAAm2cdjCz2XboJGNmrF6kAA4BbJz6ysK+KmSEKKQAcjAA7gDqrAAWAJIcYLAAtjAcGAAUAJQ8MX7CoSzhXAC8pByp/vVePlE1fgikzXWBnAB0CADUY2hKPT0a/SFhXsMaE9U1ems6a2tGCcnpWQCCTi4NFVXdfoMN860p7UMcXTM1fQOLI31jpACMU2svObvDojObfP4AkQbbpbbo7OIJACqwScshguQYuGkYBgFWeM2uSy+zR+kRehNBpDGJLJUN0giAA=

Main difference being that doing postincrement involves also writing back to the fields in the original struct, but something like this doesn't:

position = new Position{
    x = position.x + 1, 
    y = position.y + 1,
};

Good idea to make a benchmark, I'll do that now.

[Stovoy]

Benchmark: https://gist.github.com/Stovoy/04229a08b1caf699ecec69597426344f

Results:

|           Method |     Mean |   Error |  StdDev |   Median |
|----------------- |---------:|--------:|--------:|---------:|
| NewWithIncrement | 199.9 us | 3.34 us | 8.31 us | 197.0 us |
|  NewWithAddition | 194.7 us | 2.82 us | 2.35 us | 194.2 us |
|    UpdateInPlace | 193.0 us | 1.09 us | 0.85 us | 193.1 us |

My current guess is that this is some runtime-optimization coming from the JIT compiler optimizing these loops over spans.

[genaray]

Totally, nice benchmark though ! :) Finally clarifies some things. I think i will still include this into the performance category, since updating fields ( in place ) is still a bit faster.