Ref/In for better performance ?

[genaray]

First of all, thanks a lot for this awesome lib !

Would it be possible to introduce ref/in parameters for the most used operations ? This would increase the performance by a lot if structs are used as points instead of classes. Furthermore its still compatible with the normal class approach :)

[splitice]

Possibly, do you have a benchmark showing an improvement in performance?

[genaray]

Possibly, do you have a benchmark showing an improvement in performance?

Wow thanks for the fast answer ! :) No i have not... but its no secret that refs and ins are faster when structs are being used. Refs wont copy the passed struct, they act as a real reference to it. So i bet we could save a lot of possible copy operations by passing generecs as refs in certain places.

Of course we just could use classes ( which are always ref )... but i like to reduce memory usage and for my game its actually pretty important to use structs... implementing refs and ins do not have any downside ^^

[splitice]

Benchmark showing performance with class (at-least not regressing) and with struct and I'll merge.

I'm not using this library these days so I depend on such tests and data to detirmine direction.

I must admit I'm not super familiar with in/ref in C# but the C++ programmer in me tends to agree that it should be faster unless the compiler does move semantics or inlining (for what native land overlaps in .NET jit...)

[genaray]

Benchmark showing performance with class (at-least not regressing) and with struct and I'll merge.

I'm not using this library these days so I depend on such tests and data to detirmine direction.

I must admit I'm not super familiar with in/ref in C# but the C++ programmer in me tends to agree that it should be faster unless the compiler does move semantics or inlining (for what native land overlaps in .NET jit...)

Alright thanks ! So i should fork this repo, implement the changes by myself, benchmark them and if it is faster than you will merge those changes ? ^^

[splitice]

Yes

[Alumniminium]

any progress on this?