[Performance] Skip creation of records if they are used immediately

[Xyncgas]

Records are immutable objects, currently if we want to modify the data we end up creating a new record
Say we have a simple record with x y z floating point values, we change x in a function and we end up with another record that has y and z copied
if we change y immediately after changing x, we can instead have x and y modified while copying only z to the new record

[StructLayout(LayoutKind.Sequential, Pack = 4)]
        public readonly record struct MyVectorRecord(float X, float Y, float Z)
        {
            public MyVectorRecord ModifyX(float value) => this with { X = value };
            public MyVectorRecord ModifyY(float value) => this with { Y = value };
            public MyVectorRecord ModifyXY_A(float l, float r) => ModifyX(l).ModifyY(r);
            public MyVectorRecord ModifyXY_B(float l, float r) => this with { X = l, Y = r };
        }

For example, let ModifyXY_A be ModifyXY_B without creating a record from ModifyX only to be modified immediately by ModifyY even though ModifyX returns a record.
While you may have a lot functions chained together / being called, it's combining all the functions into one function essentially to modify the record without even thinking about ref or std::move unless a function specifically depend on something modified by a previous function. If ModifyX touched the field Y and ModifyY relies on it because it adds 1 to that value then yes we have something in the middle, but that may not necessarily be a record. We can put the immutable readonly record struct to a 'guarded' state while it now acts like a mutable struct but that's another story. If ModifyX never touched the field Y then ModifyY can now modify the record together with ModifyX

[CyrusNajmabadi]

@Xyncgas it's unclear what you're asking for. Can you give an example?

[CyrusNajmabadi]

What is the perf benefit shown here?

[CyrusNajmabadi]

I updated my answer please take a look

It's still unclear what you're asking for.

without even thinking about ref or std::move unless a function specifically depend on something modified by a previous function

I really can't make heads or tails of what this is trying to say. Can you clarify?

[Xyncgas]

It's ok, nvm

[ryzngard]

@CyrusNajmabadi I think I somewhat understand. In the record below

record struct MyRecord(int x, int y, int z) 
{
	public MyRecord ModifyX(int x) => this with { x = x };
	public MyRecord ModifyY(int y) => this with { y = y };
	public MyRecord ModifyZ(int z) => this with { z = z };
}

If you have this call sequence

return new MyRecord(0, 0, 0).ModifyX(1).ModifyY(2);

This would create 3 total records, with 2 copies for the mutations. That said, I don't think this is something that would heavily be considered. It would be costly to implement, and by language standards you'd be better off doing

var r = new MyRecord(0, 0, 0); // Assuming this part can't change
return r with { x = 1, y = 2 };

as supported by the language. It seems like you're asking for fluent like changes to records to be optimized by the compiler. Until we have a strong use case that would be too expensive to implement and maintain, especially for the corner case gains.

@Xyncgas do you have a real world case that this would drastically improve? With language support for similar things I can't think of one.

[Xyncgas]

Painting UI ask for a specification of where things are (layoutB.PutToLeftOf(layoutC) layoutA.PutToCenter(layoutB)) via lambda capturing.

Therefore one can rotate their screen or resize their app and the layout will be recomputed according to the specification, it feels very good when you are drawing layout in this way (declarative) and it's more clear than LayoutA with {Top = ...

Lambda capturing was utilized to say I click the 'X' button and it removes other stuffs from the screen. The way lambda capturing is used also suggests this is a functional approach and fluent interface is used along with immutable record because once a layout is produced it's not going to change but it might be used to position another layout

60fps per second, many many layout, unless JIT already knows how to optimize it the limit put to animating elements by computing their transition using interpolation between two functional specification will make me reconsider developing this feature

One break through I managed was using by ref like structure, but I went back to struct because I wasn't good enough it's too much work to keep things in stack and it's easier to write helpers that helps me draw layout better by partially applying to algorithms using function transformers that transform my algorithm to another function for code reuse

Incremental construct of object has a tendency of having temporary objects that's only used once if you've noticed, because we have a lot functions that can return a modified version of the object and the variaty of these functions brings great composibility, sometimes all the objects produced in each steps are actually used so there is some use of them and sometimes you are composing a bunch functions (putToLeft + putToRight + Center + MoveLeft + ExpandRight + Resize) / (WithKey + MutateKeyWithId + SubKeyOfKey) just to create one object