So I created an obscene amount of IC2 Nuclear Reactors(126 of them) and wanted to have computers monitor and control each one of them. However, that plan didn't go so hot as after I installed computers at each one of them. The Lua thread became fully utilized and incredibly sluggish, causing other computers in the server to perform poorly. I'm not sure if this is just an unavoidable nature of having such a large amount of computers running simultaneously or if there's some particularly problematic calls being made. The reactor computers effectively have two programs running side-by-side-- the actual reactor program and the startup program that listens for updates to the reactor program coming from a central server.
Startup Program | Reactor Program
I tried optimizing the reactor program, such as sleeping randomly between 10-15 seconds as opposed to every second. I also stopped sending constant packets to the reactor server, only sending when change is observed. However, these changes didn't make a significant enough difference to stop the Lua thread from lagging terribly. It should be noted for the startup program, I'm not regularly sending packets on the "DEPLOYMENT" protocol, only when I am deliberately updating the programs. In which case, the Lua thread is completely consumed by the process for at least half a minute(kinda to be expected).
So really, what's causing the bulk of the lag? Is it just the innate cost of operating so many computers? Does it have something to do with rednet(there are broadcasts from other computers, but not on the DEPLOYMENT protocol)? Is it the reactor peripherals? Something else?
For reference, I'm running CC 1.75 on Minecraft 1.7.10.
0
What Calls Are Expensive?
Started by brett122798, Feb 13 2022 03:49 AM
2 replies to this topic
#1
Posted 13 February 2022 - 03:49 AM
#2
Posted 13 February 2022 - 02:19 PM
I'm going to assume that the startup program isn't causing issues as it's not actually managing the reactor, it's just an auto-update utility.
As for the main program itself, I'm more familiar with CC:T on 1.16+ so some of my info may not be relevant to classic CC and older MC versions but I'll try to help anyway.
You could try reading this post: https://www.computer...o-optimization/
Also, I believe that SquidDev also improved context switching between computers, so having one computer manage multiple reactors might help as you'll minimise the amount of context swapping that the mod has to do.
As for the main program itself, I'm more familiar with CC:T on 1.16+ so some of my info may not be relevant to classic CC and older MC versions but I'll try to help anyway.
- Local variables are quicker to access than the global ones that you are using (lines 1, 2, and 10)
- The for loop on line 24 could be optimised by doing what ipairs is doing manually (not as nice code but it saves lua the effort at run time)
- Sleeping for longer on line 16 might help too.
You could try reading this post: https://www.computer...o-optimization/
Also, I believe that SquidDev also improved context switching between computers, so having one computer manage multiple reactors might help as you'll minimise the amount of context swapping that the mod has to do.
#3
Posted 15 February 2022 - 03:06 AM
Lupus590, on 13 February 2022 - 02:19 PM, said:
I'm going to assume that the startup program isn't causing issues as it's not actually managing the reactor, it's just an auto-update utility.
As for the main program itself, I'm more familiar with CC:T on 1.16+ so some of my info may not be relevant to classic CC and older MC versions but I'll try to help anyway.
You could try reading this post: https://www.computer...o-optimization/
Also, I believe that SquidDev also improved context switching between computers, so having one computer manage multiple reactors might help as you'll minimise the amount of context swapping that the mod has to do.
As for the main program itself, I'm more familiar with CC:T on 1.16+ so some of my info may not be relevant to classic CC and older MC versions but I'll try to help anyway.
- Local variables are quicker to access than the global ones that you are using (lines 1, 2, and 10)
- The for loop on line 24 could be optimised by doing what ipairs is doing manually (not as nice code but it saves lua the effort at run time)
- Sleeping for longer on line 16 might help too.
You could try reading this post: https://www.computer...o-optimization/
Also, I believe that SquidDev also improved context switching between computers, so having one computer manage multiple reactors might help as you'll minimise the amount of context swapping that the mod has to do.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users