optimize by localising math functions

[tenplus1]

optimizations by localising math functions.

[SmallJoker]

Do these changes make a measurable performance difference on your side? How big of a difference is it?

[tenplus1]

@SmallJoker - A few ms here and there, although Nether generation does feel a lot smoother.

[Treer]

I made the original local math function code that tenplus1 is adding to.

It was long enough ago that I don't recall how much speed testing I did or which lua implementation it was on. Any testing I'd done would have been in an earlier (not-nether) mod that used the same kind of mapgen. iirc I was only bothering to make local math functions if an operation was called many times in an inner loop.

The big reason to avoid potentially-premature optimization is the added code complexity/legibility/maintenance, and I don't think this applies to tenplus1's changes because they are extremely readable, and also consistent with how the code is already written, enough that they probably make the code more consistent and predictable.

So I can't say I have a problem with these changes, regardless of whether there's a noticeable performance difference. (as nice as it would be to know whether nether go faster)

[tenplus1]

le Push :P

[SmallJoker]

Test setup:

• Luanti 5.14.0-dev
• LuaJIT 2.1.0-beta3 (Ubuntu repository, libluajit-5.1-2)
• World with dummy back-end
• Teleported into a known nether location with master and PR, and explored most of the (gigantic) cavern.

Testing code:

-- (bottom lines of mapgen.lua)
minetest.register_on_generated(function(...)
	local start = core.get_us_time()
	on_generated(...)
	-- print millisecond time
	print(("%.2f"):format((core.get_us_time() - start) / 1000))
end)

	master	PR 83
Samples	95	133
Average / ms	65.56	68.99
Median / ms	61.4	64.87
Time diff. / %		5.65

Interestingly, this PR does result in decreased performance. Would you please be so nice to test this on your system?

[tenplus1]

Very strange indeed, I teleported to the nether, stood in the exact same spot and did "/deleteblocks here 20" to regenerate an area 10 times, without the changes the final block times were (67.33, 66.90, 55.16) and with the changes the final block times were (48.95, 53.17, 61.34). This is on an AMD Ryzen 7 7840HS with 780M graphics.

[tenplus1]

Last update stops the "invalid vector cooddinate z" errors.

[Treer]

Last update stops the "invalid vector cooddinate z" errors.

You wouldn't happen to know if that's a bug/regression in the lua api, or if it's now intended behaviour and the documentation hasn't been updated?

[SmallJoker]

@tenplus1

[...] final block times were (67.33, 66.90, 55.16) and with the changes the final block times were (48.95, 53.17, 61.34).

What do these three values mean? Also: is this with LuaJIT, or without?

Last update stops the "invalid vector cooddinate z" errors.

EDIT: This warning appears since luanti-org/luanti#16158 and is meant to reduce mistakes. Here it's a false-positive like the HUD API mentioned in the same PR.

That's a "bug"fix and should be done in an entirely separate PR such that this one can be squashed into one.

As how it currently stands, I am somewhat hesitant to localise everything (boilerplate code), especially when it comes to code that is executed only once per mapblock, or only upon startup.
EDIT: How does a trivial local math = math perform?