A little bit off topic, but I hope it is allowed to talk about here because it's still data oriented and kind of related to what we are going for. I would like someone with UE experience to tell me about internal data usage pattern of a class that was generated/nativized from the Blueprint. Is the engine just `new` instances of those generated class, or the engine knows how to order memory by-field for each instance? (As the user just use these normal looking methods which even return a pointer. But they are not a normal C++ `new` I don't know if any magic is in there.) The fact that they returned a pointer means you could access whatever field you want (contrary to Unity which the API guards the data very tightly, and provide specific iteration entry point) so how could the engine convert something like this to DOD at runtime? If that level of intelligence is possible it would be an equivalent of Burst. This is because lately, I have been talking a lot about the recent DOTS movement of Unity in game dev community (engine agnostic), and always someone would keep claiming that UE is already data oriented for long, he said "just that we programmed in OOP, but in runtime all the blueprints will be converted to a class which utilize memory in data oriented way." And the net don't have much information about this, the official docs is talking as deep as compilation but not at the level of how the memory is allocated and used. And I did Google with keywords involving memory, DOD, Unreal, Unity, etc. but all I could find are baseless claims. (There are both someone saying that UE is OOP behemoth, and someone saying UE is data-oriented) I hope this one show up the next time someone wondered. ps. I did some work by actually digging through the source too, so this time it is not as baseless. My deduction is that UE memory usage is like regular OOP's `new` where it allocates per instance incrementally. (No such pattern like pre-reserve a chunk to arrange data later, etc.) However I may missed something as I didn't actually use the software. So if we follow from NewObject Going to implementation of this StaticConstructObject_Internal, then likely this StaticAllocateObject After some certain checks, an object size is calculated along with required memory alignment, that goes into this In a new file I finally found a Malloc, but it seems to be just using the size of the whole object got from TotalSize earlier. In effect this is 1 object allocation and I could not see how the next object could be sliced and arrange in DOD style with the previous one. (Or did he actually just misunderstand from somewhere that UE is data oriented?) Compared to Unity's EntityManager.CreateManager which works even without malloc if the chunk is already there, just memory copy to the space we already own. And copy such that the data is spread out and make space for the next instance (entity) to come.