regarding the performance of accessing

[torpid marlin]

future me: yeah you lazy sob, add .ToArray and gain 3x speed

[wispy hawk]

Well, managed arrays have their own dedicated IL instructions for reading and writing to them, so JIT can easily optimize it.

But I think if you convert the NativeArray to a Span, you should see major improvements.

This can be done without any additional allocations, since Span can reference native memory.

Unity 2022.2+ have NativeArray.AsSpan, but you can also do it manually using GetUnsafePtr and passing that into the Span constructor. It just requires an unsafe context.

[wispy hawk]

I just tried this and got about a 50% speed improvement. Which is only a little bit faster than ToArray, except no allocation.

[arctic ingot]

and you're not profiling in the editor with safety checks on, right? Because that adds a ton of overhead that won't be present in actual use cases

[torpid marlin]

that thing toggled itself back on, I think they do that on each package update :/ Toggled it off and see no change in speed.

[maiden locust]

Oh no, 44,5mb of GC

[torpid marlin]

Never done that, that's very cool. I had a out of index thingy because I rely too much on gpt4 😄

[wispy hawk]

It's actually a 15x difference in the editor, 2x improvement in Mono build, and exactly no difference in IL2CPP.

[torpid marlin]

and same perf as ToArray but without the silly allocation

[maiden locust]

much better

still concerned about the time it takes

[torpid marlin]

i agree it is too slow. testing 5M cells i might have to make a job

[maiden locust]

Ahhh, I thought this was on jobs already, then yes, it should help, but Im curious, why is this being called everyframe on late update?

[torpid marlin]

It's how I debug stuff. The end goal is to get two disparate systems to talk.

the Draw.WireBox command is like Drawgizmo but 100x faster

[maiden locust]

Ahhh, alright, I understand

[torpid marlin]

liquid type and density, then map it to voxel. I think it'll be one system once out of proto stage.

[maiden locust]

Great! since this is the case, then jobs will boost this for sure, but keep in mind in case you are using a 2D array for voxel data, you will need to flatten it, because jobs cant take multi dimentional arrays

[torpid marlin]

and feed the voxel navigation system as well so that flying creatures dodge or dive in the liquid

compute butter.GetData spits out a flat array

[maiden locust]

Great, much easier then

another note would be to use unity mathematics instead of default unity Mathf functions, mathematics should be faster than Mathf and also are designed to work onto jobs. I am not sure if it would be necessary to convert vector3 to float3, not sure if it actually improves performance, but In my voxel project I did that just in case

[torpid marlin]

in the past mathematics had an overhead so in main thread there was a penalty, but if I jobify this I'll switch over. someone told me that vector3 is already float3 under the hood

[maiden locust]

I didn't know vector3 was a float3 already, thanks for the info thoug

[torpid marlin]

mmm from 16ms to 7ms, doesn't seem right for a paralell bursted job

[maiden locust]

deep profile the root of what takes the more ms

your ms should go lower

[torpid marlin]

on 11 threads instead of 1

yes it should be around 0.1 ms or even lower