SceneTreeFTI faster access to Node children

[lawnjelly]

Adds methods to directly access cached children from outside Node:

update_cached_children()
get_cached_children()

Helps address #106185.
Supersedes #106214.

MRP

ManyStaticColliders2.zip

Before this PR: 160fps
After this PR: 250fps
Physics interpolation off: 360fps

Discussion

#104269 introduced the new 3D FTI and uses a reference approach traversing the entire scene tree which is expected to not be super fast with large numbers of nodes in the tree. This is to be considerably optimized in #105728 (which only updates branches that have changed) and #105901.

However the reason for a lot of the slowdown in #106185 was unexpected - it was due to changes made for 4.x in #75627 which seem to make it (very?) inefficient to access children via get_child_count() and get_child(). This problem does not exist in 3.x.

This is worth optimizing because although after #105728 this MRP will no longer be an issue for static nodes, the bottleneck will still exist when moving large numbers of nodes (e.g. via a parent).

Profiling makes clear what is happening (this is debug, but should represent release to an extent):

Investigating suggested that get_child_count() and get_child() could be very inefficient, especially in debug with thread checks.

Notes

• Access via these new methods seems to benchmark at approx 16x faster than via get_child() and get_child_count().
• get_child() is slow because it includes a thread guard, updates child cache every call, branches on internal and index, and includes bounds checking.
• get_child_count() is especially slow in for loops because it includes thread guard, update to child cache, branches on internal, and math.
• Alternatives including making SceneTreeFTI a friend and accessing the cached children directly.
• I tested allowing access to the LocalVector directly versus Span, and Span is optimized out and runs as fast as the former, so is probably a more generic solution than returning the LocalVector.
• If we roll out this or similar approach, we should look through existing bottleneck child iteration code to see whether it can be improved, perhaps using the same paradigm / API. In particular as a first step, storing child_count in a local variable is an easy win in for loops.

I don't have strong opinions as to which method would be best for access:

• friend discourages use in other areas of the engine (especially while evaluating whether this will work in the wild)
• friend is usually better to use sparingly, because it makes inter dependencies in the engine less clear
• public methods allow use from other parts of the engine
• It would alternatively be possible to have wrapper functions for size and [] instead of returning a Span

[Ivorforce]

This makes sense to me. We desperately need a high performance access to node children.
Using Span for this makes sense to me since it allows to not expose which container is used internally, and it has the lowest chance of accidental overhead.

Code looks good!

[lawnjelly]

Incidentally, it would also be possible I think to use a custom Span to return the subset that doesn't include internal children, but I've left that for followup if we decide to use this from more places.

e.g.
Span<Node *> get_cached_children(bool p_include_internal) ...

[lawnjelly]

core meeting:
We've decided to go with making SceneTreeFTI a friend for now so we don't expose the API as public, and @hpvb will investigate whether we can use a different data structure for holding children in the longer term (but we will merge the approach here for now as it needs to be solved for 4.5).

I'll update the PR asap.

UPDATE:
Done.

[Ivorforce]

Re-approving after changes.

[Ivorforce]

I particularly like how this previously called get_child_count() on every loop 😅

[lawnjelly]

What can I say, it's cheap in 3.x. 😁

[Repiteo]

Thanks!