Non-statically saved objects are never deactivated

[gpcf]

Minetest version

Minetest 5.2.0 (Linux)
BUILD_TYPE=Release
RUN_IN_PLACE=0
USE_GETTEXT=1
USE_SOUND=0
USE_CURL=1
USE_FREETYPE=1
USE_LUAJIT=1
STATIC_SHAREDIR="/usr/share/games/minetest"

Summary

Objects with static_save = false are never deactivated. See This forum thread for more info. This leads to an entity flood on the server and to severe lag due to the on_step of the entities being run. This is quite bad with advtrains, which makes extensive use of ephemerous entities, that persist in this way.

[rubenwardy]

Occasionally, there are times where you see code and you think: "whhhhyyyy".
This is one of those times

[sfan5]

It's actually quite useful for WorldEdit and signs_lib

• WorldEdit area markers are persistent for the entire session even if you walk away n*1000 nodes
• signs_lib creates the entities in an LBM so deleting them before block unload would be too early

So my question here is:
Does advtrains really want the entities to be deleted when the player walks (by default) 48 nodes away?

[Hume2]

The train entities can be deleted any time, they restore shortly if they are still needed.

[gpcf]

That was the whole point of the static_save property: to prevent short-lived technical entities from cluttering the whole server.

[BuckarooBanzay]

Whats the current consensus about this issue?
I ask because as of right now the signs_lib mod causes quite the amount of entities due to them not unloading (in the 10k ballpark figure depending on usage).
Which in turn also affects every minetest.get_objects_inside_radius call because of the linear search behavior.

[gpcf]

Well, my current status is that the advtrains workaround greatly increased server performance, however, we still have issues with get_objects_inside_radius being a huge performance hog.

[gpcf]

Turns out the workaround wasn't complete and the couples still don't get deleted. Essentially all the work shifted onto advtrains developers to reinvent the wheel to fix the issue that should have been fixed with static_save = false.

[sfan5]

I know this isn't a satisfactory situation but I don't think other developers (e.g. signs_lib) would like to have the need for a workaround forced on them to continue their previous usage of static_save = false.