[Discussion] Mods performance improvements

Post Reply
User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

[Discussion] Mods performance improvements

by SaKeL » Post

How to analyze your MOD performance and how to re-factor the code to improve your MOD performance?

This discussion started with me and rnd while analyzing dedicated minetest game server performance and processor consumption per MOD when we though of sharing this in dedicated topic where everyone can contribute and share his/hers experience and solutions regarding performance improvements on (dedicated) online servers.

For measuring performance i have used these commands and settings in minetest.conf (below) what shows detailed overview of processing power consumption on live/online server with players after some time (hrs/min) being online:

Code: Select all

### Profiling

#    Load the game profiler to collect game profiling data.
#    Provides a /profiler command to access the compiled profile.
#    Useful for mod developers and server operators.
#    type: bool
# profiler.load = false

#    The default format in which profiles are being saved,
#    when calling `/profiler save [format]` without format.
#    type: enum values: txt, csv, lua, json, json_pretty
# profiler.default_report_format = txt

#    The file path relative to your worldpath in which profiles will be saved to.
#    type: string
# profiler.report_path = ""

#    Have the profiler instrument itself:
#    * Instrument an empty function.
#    This estimates the overhead, that instrumentation is adding (+1 function call).
#    * Instrument the sampler being used to update the statistics.
#    type: bool
# instrument.profiler = false
The profiler showed this output (short version):

Code: Select all

 instrumentation   |    min µs |    max µs |    avg µs | min % | max % | avg %
------------------ | --------- | --------- | --------- | ----- | ----- | ------
flowers:           |         0 |     83271 |        92 |   0.0 |  91.9 |   0.3
sethome:           |         0 |       101 |         0 |   0.0 |   4.8 |   0.0
spawners_ores:     |         0 |      1450 |        15 |   0.0 |  27.8 |   0.3
unified_inventory: |         0 |     66648 |       155 |   0.0 |  95.9 |   1.8
easyvend:          |         0 |    285937 |      1133 |   0.0 |  96.7 |   1.7
u_skins:           |         0 |    299552 |       495 |   0.0 |  97.5 |   0.5
worldedit_commands:|         0 |    227573 |        19 |   0.0 |  98.2 |   0.1
wieldview:         |         0 |      2937 |         9 |   0.0 |  36.9 |   0.1
afkkick:           |         0 |     63964 |       103 |   0.0 |  92.1 |   2.1
basic_machines:    |         0 |    546543 |      4479 |   0.0 |  99.3 |   2.0
mobs_animal:       |        50 |     70579 |       778 |   0.0 |  94.4 |   9.6
city_block:        |         0 |      3405 |         5 |   0.0 |  45.8 |   0.0
fire:              |         0 |      8213 |       181 |   0.0 |  74.2 |   1.5
protector:         |         0 |     29675 |       107 |   0.0 |  73.7 |   0.8
*profiler*:        |         1 |      1156 |        71 |   0.0 |  60.5 |   1.8
areas:             |         0 |     61730 |       176 |   0.0 |  92.4 |   3.7
hudbars:           |         0 |      1225 |        12 |   0.0 |  10.5 |   0.1
farming:           |         0 |     12077 |        50 |   0.0 |  52.0 |   0.1
enhancements:      |        10 |     58896 |       131 |   0.0 |  92.4 |   2.8
hbhunger:          |         0 |     67522 |        96 |   0.0 |  93.0 |   1.6
hbarmor:           |         0 |       490 |        10 |   0.0 |   5.9 |   0.1
mapfix:            |         0 |     40175 |         6 |   0.0 |  93.9 |   0.0
creative:          |         0 |      9628 |        31 |   0.0 |  13.4 |   0.1
bones:             |         0 |      7815 |         1 |   0.0 |  32.8 |   0.0
pbj_pup:           |         0 |       408 |         0 |   0.0 |   8.7 |   0.0
spawners_env:      |         0 |       320 |         0 |   0.0 |   4.2 |   0.0
mobs_monster:      |       129 |   1559317 |      4562 |   0.1 |  99.8 |  37.2
spawners_mobs:     |        14 |    720879 |      1866 |   0.1 |  99.1 |  20.9
give_initial_stuff:|         0 |       234 |         0 |   0.0 |   0.2 |   0.0
xpanes:            |         0 |     11758 |         3 |   0.0 |  52.3 |   0.1
beds:              |         0 |       156 |         0 |   0.0 |   4.5 |   0.0
throwing:          |         0 |      1014 |         0 |   0.0 |  16.8 |   0.0
3d_armor:          |         0 |      3001 |         5 |   0.0 |  55.4 |   0.1
mobs:              |         0 |        75 |         0 |   0.0 |   1.3 |   0.0
anticheat:         |         0 |      5789 |         4 |   0.0 |  14.6 |   0.1
mob_horse:         |         0 |     64630 |       108 |   0.0 |  81.5 |   1.5
carts:             |         0 |       659 |         0 |   0.0 |   4.6 |   0.0
chat_anticurse:    |         0 |       262 |         0 |   0.0 |   7.5 |   0.0
xdecor:            |         0 |      3043 |         2 |   0.0 |  12.7 |   0.0
sfinv:             |         0 |        57 |         0 |   0.0 |   0.7 |   0.0
obsidianmese:      |         0 |     54433 |        81 |   0.0 |  38.4 |   0.1
player_api:        |         0 |     62785 |       111 |   0.0 |  92.5 |   2.2
xban2:             |         0 |      2065 |         5 |   0.0 |  94.1 |   0.1
default:           |        21 |     62285 |       377 |   0.0 |  94.8 |   6.6
This clearly shows (copied rnd's answer):

Sorted by 'heavyness' = average cpu use per server step (0.1s?):

BIG PROBLEM (together 58% > 50%):
1.mobs_monster: | 129 | 1559317 | 4562 | 0.1 | 99.8 | 37.2
2.spawners_mobs: | 14 | 720879 | 1866 | 0.1 | 99.1 | 20.9

LOW PROBLEM (together <20%)
3.mobs_animal: | 50 | 70579 | 778 | 0.0 | 94.4 | 9.6
4. default: | 21 | 62285 | 377 | 0.0 | 94.8 | 6.6

NO PROBLEM:
5. areas: | 0 | 61730 | 176 | 0.0 | 92.4 | 3.7
6. player_api: | 0 | 62785 | 111 | 0.0 | 92.5 | 2.2

+ ALL OTHER MODS : < 20% avg cpu time

In other words, top 3 mods contribute to 67% of all cpu burden. Spawner ores perform much better cause 'ore' is a dead-inactive thing. What happens when all mods combined exceed available cpu? -> LAG. Because all the operations in progress are first completed, only then other things can continue working.

Some ideas how to fix mobs:
1. Limit number of total active mobs at any moment to reasonable number ( 100? 50?)
Some mobs do heavy things like path finding every server step - sounds extremely wasteful.

2. Improve spawning process of mob ( heavy search for spawn points is no-no)

Very interesting data, expected
protector: | 0 | 29675 | 107 | 0.0 | 73.7 | 0.8
to be little more. Also funny, afkkick mod has 2.1% while basic_machines have 2.0%, seems all the
'optimizations' i did pay off heh.

Do you have an suggestions how to improve certain MODs or do you have a problem with performance on your server? Post it here because it's the time to care more!

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

I have achieved HUGE performance improvements by replacing ABM with LBM and timers in my Mods, this i my main re-factoring approach at the moment (spawners, farming_addons - melons, pumpkins).

Sokomine
Member
Posts: 4276
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine
IRC: Sokomine
In-game: Sokomine

Re: [Discussion] Mods performance improvements

by Sokomine » Post

Mobs spawning seems to be rather expensive anyway. Sapiers animals modpack had lag when trying to spawn new mobs in existing terrain. Spawners might help but would also make mobs too predictable.
A list of my mods can be found here.

User avatar
ExeterDad
Member
Posts: 1717
Joined: Sun Jun 01, 2014 20:00
In-game: ExeterDad
Location: New Hampshire U.S.A

Re: [Discussion] Mods performance improvements

by ExeterDad » Post

Excellent topic idea. Finding documentation on the profiler and how to use it isn't trivial.

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [Discussion] Mods performance improvements

by sofar » Post

I've commented before that ABM's are incredibly inefficient, and should be avoided and replaced by other mechanisms. Entities will always be intensive, you can't get around it. If you design for performance, you might lack features or just miss out on opportunities, so don't be afraid to write code for features first and then re-evaluate.

mod_profiling is only one view of the data, don't hesitate to use `perf top` which is how you see ABM overhead (the part where C++ scans the map for ABM runs) and those don't show up in mod_profiling at all.

data == knowledge. Learn what is good data, what isn't. What is your benchmark vs. what is your real usage scenario. Throw every tool at the problem until you're satisfied.

Percentages are useless for solving a 2% usage problem, they're only useful to determine the lowest hanging fruit (iow, the largest % user, which may be outside lua!).

Data. Data. More Data.

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

@sofar good idea with the perf top
Image

The ABM was jumping between 2 - 12%

I found out after re-factoring some of my mods that ABM is really expensive, also found out that entities are always the burden. That means if you want to have challenging map full of mobs expect lag but on the other hand less fun/less mobs = less lag the choice is yours. Hope entity_ai will get to production state at some point of time, so i can give it a stress tests :)
Attachments
Selection_035.png
Selection_035.png (909.11 KiB) Viewed 1290 times

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

i have also reduced item_entity_ttl to 5min. hope that will give a small performance boost too :)

Code: Select all

#    Time in seconds for item entity (dropped items) to live.
#    Setting it to -1 disables the feature.
#    type: int
# item_entity_ttl = 900

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [Discussion] Mods performance improvements

by sofar » Post

SaKeL wrote:@sofar good idea with the perf top

The ABM was jumping between 2 - 12%

I found out after re-factoring some of my mods that ABM is really expensive, also found out that entities are always the burden. That means if you want to have challenging map full of mobs expect lag but on the other hand less fun/less mobs = less lag the choice is yours. Hope entity_ai will get to production state at some point of time, so i can give it a stress tests :)
It's 2% system wide, but how much of it is it when you press enter on that line and "zoom in on DSO/program" ?

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [Discussion] Mods performance improvements

by sofar » Post

Another important notice to people doing performance testing:

PLEASE do NOT test on a single machine if you are attempting to make your server code more optimized. You are going to be profiling both the client and the server on one machine, and this will make it much more difficult to understand the true cost of something.

ALWAYS run the server without GUI on a separate machine, and debug and profile on that machine. Then, use a remote client to connect to the server.

The same when you're doing client side optimizations - eliminating "black boxes" from your performance matrix will help and is needed to really understand where your optimization potential is, and where it is not.

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

I have down sized the mobs ABM about a half, but it seems that the `on_punch` function is taking the most resources now:

Code: Select all

mobs_monster:                                           |        10 |    203976 |      2560 |   0.1 |  98.8 |  33.1
  - ABM 'mobs_monster:spider spawning' ................  |        24 |      1414 |       317 |   0.0 |  16.0 |   3.2
  - on_activate[8] ....................................  |        22 |       484 |        65 |   0.0 |   2.9 |   0.5
  - on_step[8] ........................................  |         6 |      2215 |        36 |   0.0 |  10.4 |   0.6
  - on_punch[3] .......................................  |       164 |      3723 |       551 |   2.1 |  36.1 |  13.9
  - ABM 'mobs_monster:lava_flan spawning' .............  |        81 |      2156 |       397 |   0.1 |   4.0 |   1.8
  - ABM 'mobs_monster:dungeon_master spawning' ........  |        17 |      8544 |       692 |   0.0 |  33.1 |   3.2
  - on_step[7] ........................................  |       254 |       255 |       254 |   0.2 |   2.6 |   1.4
  - get_staticdata[5] .................................  |         7 |      1478 |       114 |   0.0 |   8.1 |   0.8
  - get_staticdata[8] .................................  |         7 |      1831 |       126 |   0.0 |   8.1 |   0.9
  - on_step[20] .......................................  |       215 |       285 |       258 |   0.2 |   8.7 |   4.9
  - on_activate[7] ....................................  |        30 |       221 |        78 |   0.1 |   1.3 |   0.5
  - on_activate[3] ....................................  |        22 |       638 |        71 |   0.0 |   4.7 |   0.5
  - get_staticdata[6] .................................  |         8 |       129 |        69 |   0.0 |   1.1 |   0.3
  - get_staticdata[9] .................................  |         8 |       840 |        91 |   0.0 |   6.7 |   0.7
  - on_step[18] .......................................  |        15 |       258 |        84 |   0.2 |  15.1 |   4.7
  - get_staticdata[2] .................................  |         8 |       278 |        80 |   0.0 |   4.2 |   0.6
  - on_step[21] .......................................  |        16 |       677 |        96 |   0.0 |  19.3 |   3.4
  - on_punch[5] .......................................  |       288 |      2205 |       563 |   2.2 |  57.9 |  22.8
  - ABM 'mobs_monster:stone_monster spawning' .........  |         1 |      9309 |       389 |   0.0 |  23.7 |   1.4
  - on_activate[9] ....................................  |        23 |       248 |        55 |   0.0 |   2.5 |   0.5
  - get_staticdata[7] .................................  |         9 |       930 |       117 |   0.0 |   3.5 |   0.7
  - on_activate[2] ....................................  |        23 |       172 |        50 |   0.0 |   1.4 |   0.4
  - on_step[10] .......................................  |        19 |     44894 |       458 |   0.0 |  91.2 |   8.5
  - get_staticdata[3] .................................  |         7 |      1613 |       141 |   0.0 |  14.8 |   1.0
  - on_activate[1] ....................................  |        23 |       402 |        65 |   0.0 |   3.2 |   0.5
  - on_step[1] ........................................  |         5 |    200398 |      1519 |   0.0 |  98.2 |   5.5
  - ABM 'mobs_monster:dirt_monster spawning' ..........  |         8 |      4639 |       354 |   0.0 |  47.2 |   3.4
  - on_step[19] .......................................  |         6 |     24370 |        82 |   0.0 |  58.7 |   1.8
  - on_punch[1] .......................................  |       189 |       679 |       365 |   0.2 |  19.8 |   8.9
  - ABM 'mobs_monster:mese_monster spawning' ..........  |         1 |      8394 |       428 |   0.0 |  25.5 |   2.0
  - on_step[12] .......................................  |         5 |       744 |        42 |   0.0 |  17.8 |   0.9
  - on_step[14] .......................................  |         5 |      8307 |        58 |   0.0 |  18.6 |   1.6
  - get_staticdata[4] .................................  |         9 |       354 |        99 |   0.0 |   0.4 |   0.3
  - on_activate[6] ....................................  |        28 |        59 |        45 |   0.1 |   0.3 |   0.2
  - on_punch[8] .......................................  |       243 |       746 |       357 |   1.7 |  36.9 |  18.3
  - on_activate[5] ....................................  |        22 |       377 |        59 |   0.0 |   2.7 |   0.4
  - get_staticdata[1] .................................  |         8 |      1175 |       121 |   0.0 |   8.6 |   1.0
  - on_step[16] .......................................  |        21 |     41647 |       447 |   0.0 |  90.5 |   7.9
  - on_activate[4] ....................................  |        27 |       108 |        48 |   0.1 |   0.2 |   0.1
  - on_step[6] ........................................  |        42 |     33211 |       592 |   0.0 |  92.8 |  10.8
  - ABM 'mobs_monster:oerkki spawning' ................  |        13 |      6755 |       521 |   0.0 |  24.1 |   2.5
  - on_punch[9] .......................................  |        26 |       842 |       106 |   0.1 |  24.3 |   3.3
  - on_step[3] ........................................  |         6 |      1747 |        38 |   0.0 |  20.2 |   1.0
i guess when all the players on the server start punching entities at the same time the processor will melt :D

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

i have balanced mobs_monsters like this:
* downsized the mobs (removed few kinds of mobs from the map and prevented spawning)
* disabled all pathfinding
* disabled all 'follow' functionality for mobs_monster
* lower the view_range to 5 in most of the mobs (2 of them have 10)
* removed drops from mobs on environmental death
* increased damage on environmnetal cause
* added day toogle true || false to all of them
* higher the chance of spawning between 7000 - 10000
* limited the height - mobs are spawnin in different height layers
* limited the light values
* limited the object count between 1 and 2
* removing far mobs
* downsized the nodes on which are the mobs spawning to 1 or 2
* lower the knockback values
* disabled 'replace'/'breeding' functionality
* replaced blood particle texture to low-res

previous profiler from 20180110T085620 used more than 50% of the processing power (8 cores):

Code: Select all

mobs_monster:                                           |        62 |     94748 |      2780 |   0.1 |  97.4 |  52.4
after balancing (points from above) its a bit better (33%) but it was only after 8hrs of running server, so ill keep an eye on it:

Code: Select all

mobs_monster:                                |         0 |    106309 |       766 |   0.0 |  99.6 |  33.0
- ABM 'mobs_monster:spider spawning' ....... |        13 |      1532 |       247 |   0.0 |  50.2 |   5.9
- on_activate[8] ........................... |        28 |       772 |        76 |   0.0 |  21.4 |   1.1
- on_punch[3] .............................. |        34 |      1262 |       357 |   0.5 |  74.1 |  22.0
- ABM 'mobs_monster:lava_flan spawning' .... |         4 |       314 |        70 |   0.0 |   9.6 |   1.3
- ABM 'mobs_monster:dungeon_master spawning' |         2 |     10394 |       367 |   0.0 |  88.8 |   5.9
- on_step[7] ............................... |       285 |      1050 |       473 |  13.7 |  41.1 |  28.5
- get_staticdata[5] ........................ |         3 |     19969 |       144 |   0.0 |  34.6 |   1.9
- get_staticdata[8] ........................ |         7 |      6153 |       118 |   0.0 |  35.1 |   1.7
- on_step[20] .............................. |       250 |      1041 |       467 |   2.1 |  40.8 |  25.0
- on_punch[2] .............................. |        52 |      5369 |       461 |   0.3 |  76.7 |  22.7
- on_step[16] .............................. |         4 |     73488 |       234 |   0.0 |  98.9 |  10.3
- on_activate[3] ........................... |        28 |      1020 |        77 |   0.0 |  22.7 |   1.0
- get_staticdata[9] ........................ |         7 |      1007 |       119 |   0.0 |  20.5 |   2.4
- on_step[18] .............................. |         8 |       357 |        31 |   0.0 |  27.1 |   1.8
- get_staticdata[2] ........................ |         7 |     11850 |       112 |   0.0 |  12.9 |   1.2
- on_step[21] .............................. |        28 |      8088 |       107 |   0.0 |  44.5 |   6.7
- on_punch[5] .............................. |        64 |      3350 |       456 |   0.3 |  70.8 |  21.3
- ABM 'mobs_monster:stone_monster spawning'  |         1 |     15152 |       344 |   0.0 |  75.6 |   5.5
- get_staticdata[1] ........................ |         7 |       988 |       108 |   0.0 |  20.2 |   2.1
- on_punch[9] .............................. |        31 |      2578 |       332 |   0.2 |  79.2 |  20.3
- on_activate[2] ........................... |        29 |      1107 |        72 |   0.0 |  17.5 |   0.9
- on_step[10] .............................. |         5 |     72344 |       328 |   0.0 |  99.3 |  15.0
- on_step[5] ............................... |        31 |     15464 |       547 |   0.0 |  87.5 |   8.1
- get_staticdata[3] ........................ |         7 |      6877 |       119 |   0.0 |  53.0 |   1.5
- on_activate[1] ........................... |        29 |      2266 |        75 |   0.0 |  31.9 |   1.4
- on_step[1] ............................... |         5 |     23728 |        56 |   0.0 |  96.3 |   3.2
- ABM 'mobs_monster:dirt_monster spawning' . |         4 |      2453 |       202 |   0.0 |  56.0 |   5.2
- on_step[19] .............................. |         5 |     61173 |        99 |   0.0 |  98.0 |   4.2
- ABM 'mobs_monster:mese_monster spawning' . |         2 |      6515 |       295 |   0.0 |  83.5 |   5.5
- ABM 'mobs_monster:oerkki spawning' ....... |         2 |      8657 |       377 |   0.0 |  85.3 |   6.3
- on_punch[8] .............................. |        67 |      1612 |       449 |   0.1 |  51.7 |  21.1
- on_activate[5] ........................... |        28 |      2111 |        86 |   0.0 |  15.1 |   1.2
- on_step[6] ............................... |         5 |     65934 |        98 |   0.0 |  95.5 |   4.2
- on_activate[9] ........................... |        29 |       471 |        80 |   0.0 |   8.3 |   1.6
- on_punch[1] .............................. |       275 |      2409 |       496 |   0.7 |  66.7 |  19.8
- on_step[3] ............................... |         5 |     23959 |        60 |   0.0 |  98.3 |   2.6
The most of the 33% processing power is used for on_punch and on_step functions - this should be the main focus for optimization! If you have any ideas please share them with me. i.e. looking for nodes/entities in radius or getting the node definitions on on_step is highly cost inefficient - could be limited to every 10-20 sec. or only when met certain conditions.

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

The best performance improvement was removing about 200 000 deprecated player files and cleaning up auth.txt, so i wrote a mod for it https://bitbucket.org/minetest_gamers/j ... l/overview This is based on player backed files (supports Linux by default)

the only challenge is that player files are not removing after minetest.register_on_shutdown and i cannot find a workaround it.

Inspired by rnd oldplayer but reverted logic.. this is based on newplayer instead.

turducken
Member
Posts: 23
Joined: Fri Feb 02, 2018 01:43

Re: [Discussion] Mods performance improvements

by turducken » Post

SaKeL wrote:I have down sized the mobs ABM about a half, but it seems that the `on_punch` function is taking the most resources now:

Code: Select all

mobs_monster:                                           |        10 |    203976 |      2560 |   0.1 |  98.8 |  33.1
  - ABM 'mobs_monster:spider spawning' ................  |        24 |      1414 |       317 |   0.0 |  16.0 |   3.2
  - on_activate[8] ....................................  |        22 |       484 |        65 |   0.0 |   2.9 |   0.5
  - on_step[8] ........................................  |         6 |      2215 |        36 |   0.0 |  10.4 |   0.6
  - on_punch[3] .......................................  |       164 |      3723 |       551 |   2.1 |  36.1 |  13.9
  - ABM 'mobs_monster:lava_flan spawning' .............  |        81 |      2156 |       397 |   0.1 |   4.0 |   1.8
  - ABM 'mobs_monster:dungeon_master spawning' ........  |        17 |      8544 |       692 |   0.0 |  33.1 |   3.2
  - on_step[7] ........................................  |       254 |       255 |       254 |   0.2 |   2.6 |   1.4
  - get_staticdata[5] .................................  |         7 |      1478 |       114 |   0.0 |   8.1 |   0.8
  - get_staticdata[8] .................................  |         7 |      1831 |       126 |   0.0 |   8.1 |   0.9
  - on_step[20] .......................................  |       215 |       285 |       258 |   0.2 |   8.7 |   4.9
  - on_activate[7] ....................................  |        30 |       221 |        78 |   0.1 |   1.3 |   0.5
  - on_activate[3] ....................................  |        22 |       638 |        71 |   0.0 |   4.7 |   0.5
  - get_staticdata[6] .................................  |         8 |       129 |        69 |   0.0 |   1.1 |   0.3
  - get_staticdata[9] .................................  |         8 |       840 |        91 |   0.0 |   6.7 |   0.7
  - on_step[18] .......................................  |        15 |       258 |        84 |   0.2 |  15.1 |   4.7
  - get_staticdata[2] .................................  |         8 |       278 |        80 |   0.0 |   4.2 |   0.6
  - on_step[21] .......................................  |        16 |       677 |        96 |   0.0 |  19.3 |   3.4
  - on_punch[5] .......................................  |       288 |      2205 |       563 |   2.2 |  57.9 |  22.8
  - ABM 'mobs_monster:stone_monster spawning' .........  |         1 |      9309 |       389 |   0.0 |  23.7 |   1.4
  - on_activate[9] ....................................  |        23 |       248 |        55 |   0.0 |   2.5 |   0.5
  - get_staticdata[7] .................................  |         9 |       930 |       117 |   0.0 |   3.5 |   0.7
  - on_activate[2] ....................................  |        23 |       172 |        50 |   0.0 |   1.4 |   0.4
  - on_step[10] .......................................  |        19 |     44894 |       458 |   0.0 |  91.2 |   8.5
  - get_staticdata[3] .................................  |         7 |      1613 |       141 |   0.0 |  14.8 |   1.0
  - on_activate[1] ....................................  |        23 |       402 |        65 |   0.0 |   3.2 |   0.5
  - on_step[1] ........................................  |         5 |    200398 |      1519 |   0.0 |  98.2 |   5.5
  - ABM 'mobs_monster:dirt_monster spawning' ..........  |         8 |      4639 |       354 |   0.0 |  47.2 |   3.4
  - on_step[19] .......................................  |         6 |     24370 |        82 |   0.0 |  58.7 |   1.8
  - on_punch[1] .......................................  |       189 |       679 |       365 |   0.2 |  19.8 |   8.9
  - ABM 'mobs_monster:mese_monster spawning' ..........  |         1 |      8394 |       428 |   0.0 |  25.5 |   2.0
  - on_step[12] .......................................  |         5 |       744 |        42 |   0.0 |  17.8 |   0.9
  - on_step[14] .......................................  |         5 |      8307 |        58 |   0.0 |  18.6 |   1.6
  - get_staticdata[4] .................................  |         9 |       354 |        99 |   0.0 |   0.4 |   0.3
  - on_activate[6] ....................................  |        28 |        59 |        45 |   0.1 |   0.3 |   0.2
  - on_punch[8] .......................................  |       243 |       746 |       357 |   1.7 |  36.9 |  18.3
  - on_activate[5] ....................................  |        22 |       377 |        59 |   0.0 |   2.7 |   0.4
  - get_staticdata[1] .................................  |         8 |      1175 |       121 |   0.0 |   8.6 |   1.0
  - on_step[16] .......................................  |        21 |     41647 |       447 |   0.0 |  90.5 |   7.9
  - on_activate[4] ....................................  |        27 |       108 |        48 |   0.1 |   0.2 |   0.1
  - on_step[6] ........................................  |        42 |     33211 |       592 |   0.0 |  92.8 |  10.8
  - ABM 'mobs_monster:oerkki spawning' ................  |        13 |      6755 |       521 |   0.0 |  24.1 |   2.5
  - on_punch[9] .......................................  |        26 |       842 |       106 |   0.1 |  24.3 |   3.3
  - on_step[3] ........................................  |         6 |      1747 |        38 |   0.0 |  20.2 |   1.0
i guess when all the players on the server start punching entities at the same time the processor will melt :D
I had to remove a modified "minerdream" mod from my server because it called on_punch way to much. It had nice new armors and weapons, but the lag got to be too much with only four players. Seems it was called whenever anything punched anything. It was ridiculous.

I see similar performance issues when enabling mobs_mc, the server drags to a halt. However, I can run multiple other mob packs fine. Definitely mobs are a bottle neck.

Lastly, I recently started profiling my server and moretrees ABM are high on the usage tree. Could be from new players exploring new map sections, and trees growing from saplings. That's my understanding of how it works.

User avatar
texmex
Member
Posts: 1753
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: [Discussion] Mods performance improvements

by texmex » Post

Excellent thread for learning more about this. All modders should read it.

User avatar
Festus1965
Member
Posts: 4181
Joined: Sun Jan 03, 2016 11:58
GitHub: Festus1965
In-game: Festus1965 Thomas Thailand Explorer
Location: Thailand ChiangMai
Contact:

Re: [Discussion] Mods performance improvements

by Festus1965 » Post

Some example from my server, no monsters no PvP as for kids and still only lag with 0.09 up to 0,2 mainly

39,5 %, pipeworks (--> lead to own globalstep code changes)
10,5 %, mesecons
10 %, adv_spawning
7,8 %, carts
7,1 %, technic, hier switching stations
4,4 %, areas
4,3 %, mobs_animals
4 %, time (a hud with time und lag)

so depending on what takes most I have to look at pipeworks and reduced the pipes a lot, but the game depends on this service, so ... keep watching.

What command did you use ?
SaKeL wrote:@sofar good idea with the perf top
top or perf, and ... there ?
Last edited by Festus1965 on Tue Jun 30, 2020 03:41, edited 2 times in total.
Human has no future (climate change)
If urgend, you find me in Roblox (as CNXThomas)

User avatar
SaKeL
Member
Posts: 743
Joined: Tue Apr 14, 2015 18:39
GitHub: JurajVajda
IRC: SaKeL
In-game: SaKeL

Re: [Discussion] Mods performance improvements

by SaKeL » Post

@Festus1965 `perf top`: https://perf.wiki.kernel.org/index.php/ ... h_perf_top
Its just for checking the ABM performance with the system monitor (perf top), i find the `profiler` much more useful though.

User avatar
joe7575
Member
Posts: 851
Joined: Mon Apr 24, 2017 20:38
GitHub: joe7575
In-game: JoSto wuffi
Location: Germany, in the deep south

Re: [Discussion] Mods performance improvements

by joe7575 » Post

SaKeL wrote:I have achieved HUGE performance improvements by replacing ABM with LBM and timers in my Mods, this i my main re-factoring approach at the moment (spawners, farming_addons - melons, pumpkins).
Could it be that timers are not covered by the measurement at all?
I have some mods using only timers and no LBM/ABM and these mods are not shown in the profiling report.

If so, the "HUGE performance improvements by replacing ABM with LBM and timers" are only measurement failures?
Sent from my Commodore 64. Some of my Mods: Tech Age, TechPack, Hyperloop, Tower Crane, Lumberjack, vm16, Minecart, Signs Bot.

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [Discussion] Mods performance improvements

by sofar » Post

joe7575 wrote: If so, the "HUGE performance improvements by replacing ABM with LBM and timers" are only measurement failures?
No, but it is indeed difficult to quantify the performance impact, due to the way that the engine implements them.

The bottom line is that ABM's are expensive because even before your ABM callback gets invoked, the engine has likely done a ton of work already, and you are not seeing the cost of that. That is because most ABM's have a `chance` modifier that forces the engine to constantly process blocks and figure out if there is a need to call the callback, or look at `neighbors` and again spend time looking at every node the ABM matches with. This overhead doesn't show up in Lua profiling, because it happens in C++. Now, you may think it's much more efficient in C++, but the ABM code has no choice but to process ABM's for hundreds of thousands of nodes per second in many cases.

With LBM's the problem is reduced because they are only active when a mapblock is loaded. This is an infrequent and non-continuous task. It could be costly, but once a block is loaded, the chances are extremely high that for a significant amount of time the LBM won't need to do any work. So this is a great improvement already.

Both these methods however have an extremely low "accuracy" - with that I mean that they have to perform a lot of actions before the actual Lua code is called for a node. They are essentially very wasteful - there is a hidden cost and this hidden cost may be very high.

Node Timers are completely non-wasteful in that sense. The core needs to perform zero overhead for them if you compare it with ABM and LBM code, so this method is highly accurate. Of course, it requires much more thoughtful Lua code to make sure the mechanisms still work properly.

User avatar
joe7575
Member
Posts: 851
Joined: Mon Apr 24, 2017 20:38
GitHub: joe7575
In-game: JoSto wuffi
Location: Germany, in the deep south

Re: [Discussion] Mods performance improvements

by joe7575 » Post

But that means, you can't measure the improvement from ABM to timer routines by means of the profiling mod.
Are there any plans to provide a profiling feature in the Minetest engine which is able to cover the complete LUA code?
Or is there a profiling API which can be used from e.g. node timers?
(I know I can measure the runtime of my routines by means of minetest.get_us_time(), but that's not the same then a percentage value over hours)
Sent from my Commodore 64. Some of my Mods: Tech Age, TechPack, Hyperloop, Tower Crane, Lumberjack, vm16, Minecart, Signs Bot.

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [Discussion] Mods performance improvements

by sofar » Post

joe7575 wrote:But that means, you can't measure the improvement from ABM to timer routines by means of the profiling mod.
That's an oversimplification. You can certainly use mod_profiling, and it will give valuable data, even for ABMs, it's just that you need to understand what that data means and be OK with the fact that the data from mod profiling omits CPU time spent in some cases in the c++ core. But that doesn't mean that you can't use it at all, or that the data that it provides is unusable or incorrect.

User avatar
Hybrid Dog
Member
Posts: 2828
Joined: Thu Nov 01, 2012 12:46
GitHub: HybridDog

Re: [Discussion] Mods performance improvements

by Hybrid Dog » Post

Maybe you could automatically count how often each lua function is executed and every globalstep, output the counts and reset them.

‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪‮
‮‪

Astrobe
Member
Posts: 571
Joined: Sun Apr 01, 2018 10:46

Re: [Discussion] Mods performance improvements

by Astrobe » Post

SaKeL wrote:i have balanced mobs_monsters like this:
* downsized the mobs (removed few kinds of mobs from the map and prevented spawning)
* disabled all pathfinding
* disabled all 'follow' functionality for mobs_monster
* lower the view_range to 5 in most of the mobs (2 of them have 10)
* removed drops from mobs on environmental death
* increased damage on environmnetal cause
* added day toogle true || false to all of them
* higher the chance of spawning between 7000 - 10000
* limited the height - mobs are spawnin in different height layers
* limited the light values
* limited the object count between 1 and 2
* removing far mobs
* downsized the nodes on which are the mobs spawning to 1 or 2
* lower the knockback values
* disabled 'replace'/'breeding' functionality
* replaced blood particle texture to low-res
I'm quite puzzled by some of the items on this list. I'd like to elaborate why in order to be contradicted and understand better the performance factors.

* lower the view_range to 5 in most of the mobs (2 of them have 10)
This one is an entity scan not a block scan, which should basically boil down to scanning a relatively short list of entities and computing distance, which should be cheap.

* removed drops from mobs on environmental death
This is a once in a while event and shouldn't put a constant charge on the CPU

* higher the chance of spawning between 7000 - 10000

Mobs redo uses ABMs to spawn mobs, so reducing chances shouldn't do anything aside from making re-population longer. I think setting a longer interval and compensate with a higher chance could work better because of less frequent ABM activations.

* lower the knockback values

Knock-back is also an infrequent event, and in any case just alters the velocity vector of an entity. It doesn't matter if it's a slap in the face or a kick to the moon.

* replaced blood particle texture to low-res

The server only holds one copy of it, and we're talking about something that's less than a kilobyte. I expect that it is sent to the clients just once (it is used as a particle effect). I've heard that particle effects can be problematic, but I've also heard they are handled client-side so it shouldn't affect the server.
My game? It's Minefall.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests