Receiving/updating map chunks creates huge CPU usage

[ElementW]

Digging and also placing nodes (i.e. updating) creates high and relatively long-lasting and intensive CPU spikes, not causing slowdowns but high CPU heat-up. In the same fashion, moving around in an already-generated world and loading/receiving map chunks (vanilla LAN server) ends up in ~75% CPU hog on the client.

Graph obtained with the Multiload XFCE plug-in, 350 ms update interval. Brown is IOWait, Red is kernel time, Blue is userspace time. 16 iron ore nodes were dug with a diamond pickaxe.
The spikes are seemingly caused by new map chunks display (changing head orientation).

[RobertZenz]

Maybe related with #3166?

[est31]

@RobertZenz I don't think so. 3166 is about game mods that change node metadata often, and happens in mapblocks that are already loaded. What @gravgun seems to complain about is mesh generation lag, deflate overhead or something.

[paramat]

Not necessarily a bug, apparently every time the crack animation moves to a new frame there is a mesh update for the whole block, making a good case for not using the crack animation. Also removing or adding nodes causes lighting updates.

[est31]

@paramat you can play the networked multiplayer release if you want, its small and simple as you like it.

[Fixer-007]

I've noticed that problem too.

[RealBadAngel]

Solution to it was made quite long time ago but was rejected.
Ive simply dropped the cracks animation and replaced it with particles and tweaking highlighting halo.
No mapblock mesh updates were needed then (and thats the reason for such spikes)

[paramat]

est31 =P

I support the option of disabling the crack animation.

[HybridDog]

l thought the crack animation, like the selection box, is put into a free mesh…

I'm not even surprised.

me neither

When l load a few chunks in singleplayer mode and then press r to activate full viewing range, minetest freezes and l need to kill it from terminal.

[Fixer-007]

Any way to make it render as separate mesh overlayed on top of target block?

[ElementW]

@Fixer-007 Which is the most sensible and logical thing to do, that isn't done.
I'm not even surprised.

[nerzhul]

i think this one can be closed. the engine has changes many and we don't have the mod context.
@ElementW if you can reproduce now on the 5.2 it can be fine, especially with a vanilla minetest_game

[paramat]

I agree, closing.

[ElementW]

The situation is indeed much better, as can be seen on the graph below (relative to 100% use of my 2virt×2phys core Intel 3317U; timescale 1s/pixel), with the central span being digging, surrounded by idling.
Git revisions: 6cf15cf, minetest/minetest_game@36b2bcb

[paramat]

Thanks for the retest.