Jump to content




What Calls Are Expensive?


2 replies to this topic

#1 brett122798

  • Members
  • 300 posts
  • LocationIn the TARDIS at an unknown place in time.

Posted 13 February 2022 - 03:49 AM

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.

#2 Lupus590

  • Members
  • 2,028 posts
  • LocationUK

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.
  • 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.
Honestly, I think you have reached a limitation of old CC, SquidDev (the former maintainer of CC:T) did a lot to optimise CC/CC:T for running many computers (to the point that people have had to edit rednet because it ran out of Ids).

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 brett122798

  • Members
  • 300 posts
  • LocationIn the TARDIS at an unknown place in time.

Posted 15 February 2022 - 03:06 AM

View PostLupus590, 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.
  • 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.
Honestly, I think you have reached a limitation of old CC, SquidDev (the former maintainer of CC:T) did a lot to optimise CC/CC:T for running many computers (to the point that people have had to edit rednet because it ran out of Ids).

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.
Thank you, the post is insightful. Considering how increasing the sleeping periods by 10-15x only made small impacts, I'd have to imagine the problem is either the sheer amount of computers, or something else not directly relating to that code. I opted to forfeit the meltdown preventing capability and just have two turtles work on reading all of the reactors and reporting the data.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users