DirectSpaceState3D::intersect_ray/shape being slower that the equivalent node

[Jeghams]

It is a known issue that the physics api for ray casting and shape casting is slower (up to 5x) than the equivalent RayCast3D, ShapeCast3D nodes. Currently, when performance is critical, the most efficient way to ray/shape cast is to have node (often as an autoload) that we reuse to get the results, it doesnt really make sense that a node is faster than the lower level api, the whole point of the api is to skip the overhead of nodes and have as thin of a layer as possible, i'm not entirely sure what is the cause of this , it is most likely because these methods return a Dictionary which's creation is more expensive than the physics query itself, there must be an overlook somewhere but we should have a a way to efficiently query the physics server.
I made a discussion instead of an Issue because i don't know what need to change or where really the bottleneck is, i suspect its the Dictionary.

[theraot]

I wonder if having it take a callback would be better. Anyway, as far as I know that API is on hold until GDScript get "struct"s (which are not structs).

[Jeghams]

i wonder if simply making a RayResult class and returning that would make it faster , or if its even the Dictionary being the problem or something else (hard for me to determine because i dont know c++) , i would be very surprised if constructing a Godot Dictionary with like 6 keyvalue pairs would be that much more expensive than making a physics query

[theraot]

@Jeghams To make the query we are already making an instance of an class (e.g. PhysicsRayQueryParameters3D). Ideally we would reuse these, since they hold the parameters, and those we would be saving on allocations.

On a similar vein we can imagine having the same object hold the result, and that way we can address the allocation of the Dictionary. Of course that means it does no longer holds only parameters, yet as long as we are not sharing it across threads that is not an issue.

Then we can imagine the same class do the physics call internally (since it is silly that we would be passing it to a physics server call, and that is the main functionality). Overall that the results is a class that looks similar to the RayCast3D, except it is not a Node3D (so we don't have to add it to the scene tree in exchange of not having a gizmo) and does queries on demand (being unable to do them automatically and lacking signals). This reminds me of what they did with Tween.

Perhaps this idea would be better API for coding first programming.