A little mapgen benchmark

[burli]

I'm curious, so I added some os.clock() commands to my cavegen to see what happens. I measured the time that is needed by the "system", e.g. get_mapgen_object() or calc_lighting() and the time for the mapgen itself.

The first result: the time is not effected by the database backend. I would expect that redis or leveldb have a positive effect on storage time, but obviously not.

The "system" needs on my PC an average time of around 0.17sec under the surface, at surface level the average time increases to 0.21 and more. I guess because of the lightning calculation on the surface

The "mapgen" starts with an average around 0.04 and stays there for a while, but increases up to 0.3 and maybe more, if I play longer.

And thats the part I don't understand. I know, that memory usage increases over time, but the mapgen part is only the loop, where nodes are replaced in the vm data block.

And it seems that there is no linar relationship between the number of replaced nodes and the time, that is needed. Sometimes 50000 nodes are generated faster than 5000 nodes

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

17   290   18420
system: 0.12583   av: 0.12119
mapgen: 0.02675   av: 0.04463

17   275   18399
system: 0.13494   av: 0.12225
mapgen: 0.01144   av: 0.04208


In this case 18420 nodes needed 0.026 seconds, the next cave with nearly the same amount of 18399 nodes needs less than half the time.

The average mapgen time was stable at 0.4 for about 3-4 minutes. Then it increases rapidly within another 3-4 minutes to this

But this is not reproducable. Next time I start the map I could play over 15 minutes without any significant rise of the average times.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

12   206   20911
system: 0.13824   av: 0.16026
mapgen: 0.22952   av: 0.19194

9   162   20785
system: 0.15020   av: 0.16023
mapgen: 0.35357   av: 0.19240


There is even a huge difference if no node is generated at all because the cave is above the surface

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

11   169   0
system: 0.24761   av: 0.21818
mapgen: 0.06239   av: 0.01270

11   190   0
system: 0.31522   av: 0.21774
mapgen: 0.00432   av: 0.01177
v6caves time: 0.31980


For the first cave the mapgen loop needs more than 10 times longer


Then I added a timer for the main carving loop. Every time I start the game the average value is different. Sometimes the average value is 0.000011, sometimes the time starts with 0.000032. But the time for this loop always rises slowly over time.

What happens there? Is the LuaJit interrupted by multitasking? However, the execution time of a mapgen is not predictable

[qwertymine3]

Code used for the benchmark?

I've also had fun with timing mapgen. I had some code which would execute in 0.1, 0.2 or 0.5 seconds, for each mapblock. The time was consistent for all mapblocks, but changed every time the test map was loaded.

Made a minor change and it became a consistent 1 second : (.

[burli]

I attached the code "as is"

[duane]

I did a lot of detailed benchmarking while working on the valleys mapgen code (in c++). On my system, I noticed the same increasing times, but never figured out why.

Fortunately, mapgens aren't the heart of the game. They only come into play when you're moving into a new area.

Something to consider -- don't trust the time on anything that uses the discs unless you've completely disabled caching (which is next to impossible these days).

[burli]

Well, I noticed that while I play a normal game. First everything is OK, but the longer I played the longer it takes to build the mapchunk.

Yesterday I start a test game as server and logged in from another PC. I just walked around for a while until the world ends. It took about two minutes until the next mapchunks are loaded.

I don't have high end hardware, but this was ridiculous.