Array.CreateInstance about arch HOT 3 CLOSED

Just ported the Sample to FNA which is more NativeAOT friendly and it runs fine with some tweaks [removed the managed Texture2D field from the Sprite struct

from arch.

• the compiler cannot predict the bytes size in memory, this is done during the runtime. So we could have a waste of resources here

Using the generic overloads actually registers components during "compile time" ( or atleast the first time they are being invoked ). Thats why i added API like: world.Create<Position, Velocity,...>(...);. This is already as efficient as it can get, since the compile time static Component<T> is being used :)

Using the type based approach however will determine during runtime, but theres no way around it... since types are used.

• accessing to a component might be slower when using the Unsafe.As API for the reason above (things get done runtime side)

It depends, receiving an array from a Chunk is actually a O(1) operation. A internal lookup array is being used (chunk.ComponentIdToArrayIndex) to get the index of the component array which is the most efficient way... Only a direct field acess is faster.

• the app cannot use the nativeaot optimizations (disable reflection) if the users wants (need to try out tbh)
  As far as i know, Array.CreateInstance is not being stripped out. So it should actually work, i think i also already ran it once in nativeaot. However we should probably retry this to see if it still works.

I was wondering if it's worth to replace the managed Array.CreateInstance with an opaque unmanaged pointers pool.

The problem with umanaged memory is that its way more restrictive. With unmanaged memory, we could not use managed structs as components anymore public struct Texture{ Texture2D... } and therefore its usage with monogame, godot or unity would be a very very bad experience. I actually had a branch where i used a combination of unmanaged memory and managed arrays to simulate this. However according to benchmarks it was not faster, it performed the same.

from arch.

Just ported the Sample to FNA which is more NativeAOT friendly and it runs fine with some tweaks [removed the managed Texture2D field from the Sprite struct

Thats great to hear :D

from arch.