Closed S-S-X closed 2 years ago
Merged this PR on the test-server and got this:
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: ServerError: AsyncErr: environment_Step: Runtime error from mod 'technic' in callback environment_Step(): ...dmods/technic/technic/machines/register/machine_base.lua:111: attempt to call method 'is_empty' (a nil value)
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: stack traceback:
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: ...dmods/technic/technic/machines/register/machine_base.lua:111: in function <...dmods/technic/technic/machines/register/machine_base.lua:81>
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: /data/world//worldmods/technic/technic/machines/network.lua:459: in function 'run_nodes'
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: /data/world//worldmods/technic/technic/machines/network.lua:505: in function 'network_run'
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: ...echnic/technic/machines/switching_station_globalstep.lua:68: in function 'globalstep'
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: /data/world//worldmods/monitoring/builtin/globalstep.lua:32: in function </data/world//worldmods/monitoring/builtin/globalstep.lua:24>
minetest_1 | 2021-09-09 13:28:54: ERROR[Main]: /usr/local/share/minetest/builtin/game/register.lua:422: in function </usr/local/share/minetest/builtin/game/register.lua:406>
Yeah, I've also just noticed that there's no is_empty
for inventory lists.
However I looked at base machine code bit closer yesterday and decided to go through technic_run function there.
Already done some more optimization stuff there and also fixing these invalid inventory list usages.
I think I've fixed it... and some additional shortcuts to bypass loops and engine side API access when it is not needed. We'll see if tests pass at least...
Btw, this second addition needs testing (processing part). I'm not sure if skipping some core API stuff but using it more in some other situations is better or worse. Did not test that part at all. Actual functionality should be fine but it does affect way how output stacks are filled: always in slot order instead of prioritizing stack with space for item.
If you think it is better then I can split this to original simple bypass for empty machines and another part for actual processing.
I think there's something wrong with this, not sure what. It seems to work but have to check and actually do some testing with some pressure for machines based on machine_base to find out real difference.
Updated the technic mod on the test-server with this branch and tested a bit, everything looks good so far, no crashes, malfunctions or duplicated items :+1: Haven't done any useful lag measurements though..
If you think it is better then I can split this to original simple bypass for empty machines and another part for actual processing.
Nah, i think its ok, the diff isn't that huge yet :wink:
Updated the technic mod on the test-server with this branch and tested a bit, everything looks good so far, no crashes, malfunctions or duplicated items 👍 Haven't done any useful lag measurements though..
If you think it is better then I can split this to original simple bypass for empty machines and another part for actual processing.
Nah, i think its ok, the diff isn't that huge yet 😉
I'll try to get back to this at some point later, this is only useful if it actually provides better performance for machine execution (there's big potential for this if it does actually limit calling core API functions).
However I currently have no idea if those are reduced significantly or not, performance also has to be tested with real engine because it is exactly unnecessary calls to ItemStack
and other core stuff.
For ItemStack I've determined before that simple Lua implementation with string parsing (find
, sub
, match
) is at least twice as fast as core API calls. Some functions can be faster when core API is used, it is more about Lua - C++ bridge that slows things down significantly.
This is outdated but please do not kill pr/branches just yet, I'd like to keep this as a reminder until affecting pull requests are handled and after that possibly redo things here on top of master branch.
Simple optimization, allows skipping multiple unnecessary function calls some of which are on expensive side.