Optimize add_area_node_boxes in collision code

[sfan5]

probably(?) nobody has a perf problem with collision in the real world but I did this anyway

this PR is essentially just three simple optimizations. nothing complex.

References

relates to #15227

somewhat addresses the root cause of #15208: the "load" is now 16² not 16³

To do

This PR is Ready for Review.

How to test

I used a very unscientific benchmark by letting the client perform collisions in any direction:

diff --git a/src/client/client.cpp b/src/client/client.cpp
--- a/src/client/client.cpp
+++ b/src/client/client.cpp
@@ -22,6 +22,8 @@
 #include "client/mesh_generator_thread.h"
 #include "client/particles.h"
 #include "client/localplayer.h"
+#include "collision.h"
+#include "content_cao.h"
 #include "util/auth.h"
 #include "util/directiontables.h"
 #include "util/pointedthing.h"
@@ -550,6 +552,16 @@ void Client::step(float dtime)
 		{
 			counter = 0.0;
 			sendPlayerPos();
+
+			ScopeProfiler sp(g_profiler, "collide test", SPT_AVG, PRECISION_MICRO);
+			v3f pos = player->getPosition();
+			for (auto dir : g_6dirs) {
+				v3f speed;
+				collisionMoveSimple(&m_env, this,
+					player->getCollisionbox(), 0, 0.25f,
+					&pos, &speed, v3f(dir.X, dir.Y, dir.Z) * 200 * BS,
+					player->getCAO());
+			}
 		}
 	}
 

(keep position and world the same ofc)
this showed 0-60% faster times

[lhofhansl]

Tried with a modified entity that creates two ones when destroyed. Still works fine, but I see no performance improvement in my case. After 1000 entities it crawls to halt at less than 10 FPS.

[sfan5]

Yeah it won't change the fixed overhead. You are more likely to measure a difference with high-speed entities.

[SmallJoker]

	master / us	PR / us
median	6.8	4.5
average	6.7	4.5
std. deviation	0.9	0.5

Sample size: 30
Joined the same dummy backend world in the same spot and profiled the function call with

// in add_area_node_boxes
ScopeProfiler sp(g_profiler, __func__, SPT_AVG, TimePrecision::PRECISION_MICRO);

The code makes sense, thus 👍. I'm still surprised that getNodeBlockPosWithOffset + getBlockNoCreateNoEx + MapBlock::getNodeNoCheck is apparently faster than Map::getNode.