Can IComponentData have properties instead of fields and still be good for memory layout?

Unity Engine
, ,
1

For my implementation it would be easier to create components with properties instead of fields because of easly accessible getter and setter. Can I use properties instead of fields or it’s bad for memory layout?

2

I never tested it myself, but it shouldn’t be a problem. However, properties have an overhead (each access is a method call) but should only become noticeable with large amounts of data.

3

Are you sure about that overhead? My understanding is that this will generally be inlined and end up being free. Of course, if you have getters and setters with bodies then the code in the body will have to run, but even that would usually be inlined I think.

This should be true both in and out of Burst. I think the JIT should take care of it in managed code.

4

It’s not bad for memory layout you just lose the ability to use explicit layouts. I would use the idioms Unity uses in their own code on this just to be safe. Properties for things that have some concrete reason to be properties other then preference. Ie a get that returns a related value, set that does some work to set the value. Or if you want set to be private/internal for reasons. Etc…

5

I tested it with .NET core, 100,000 times write an property vs field:

Field: 0.032s
Property: 0.201s

But it is just a simple test and I give no guarantee

Edit:
After changing the data class to an struct and loop over int.MaxValue, the time is the same. But only with .NET Core.

.NET CORE:
Field: 0.6s
Property: 0.6s

Unity 2020.1 (Editor):
Field: 7.6s
Property: 18.7s

6

Unity editor doesn’t have optimization enabled, so of course it will be slower. When optimization is turned on, you should see zero difference in Mono.

7

I will test .NET core later in debug mode, then you should be able to compare it better.

8

.Net CORE debug:

Field: 6.2s
Property: 8.3s

Is still faster than mono, especially properties

1 Like
9

Thanks for doing all the tests.

Yup; Mono is slow as molasses, and it gets worse when things get more complex (the grabage collector in particular is very poor). @xoofx integrated .NET Core for a hackathon project: https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/ .

There were some tests here, and the performance is only slightly worse than Burst, about 2x-6x better than the current scripting runtime: https://discussions.unity.com/t/762268

Sadly, I doubt it will ever land in the actual version since it’s not portable to mobile or switch, and because DOTS is all about getting stuff out of .NET/GC land entirely. But even if most of the runtime stuff can be done in ECS, there’s always load-time code, editor stuff, legacy code, etc that’s just begging for a decent scripting runtime and garbage collector.

10

.NET Core will never land on Unity but the successor .NET 5.
However, NET Core for DOTS runtime has been confirmed.

2 Likes