Alright, so fortunately the events always seem to appear in the order in which they were requested, so the custom coroutine management was simple to implement.
In my tests, I found that WorldPorter defaulted to around 10k blocks per minute with 230 coroutines, and did about 33k bpm with 28 coroutines.
With the new code, it still ticks along at 33k bpm with 28 coroutines, but manages 156k when cranked back up to 230. That's a bit of an improvement - it's about the same speed at which it can build. :)/>
In
the source, the old "parallel.waitForAll(unpack(scanfuncs))" line has been replaced with this chunk:
local scanfuncs, curFunc = {}, 1
for i = 1, maxSeekerFuncs do
scanfuncs[i] = coroutine.create(checkPos)
coroutine.resume(scanfuncs[i])
end
while true do
local myEvent = {os.pullEvent()}
if myEvent[1] == "timer" then
coroutine.resume(displayProgress, unpack(myEvent))
elseif myEvent[1] == "task_complete" then
coroutine.resume(scanfuncs[curFunc], unpack(myEvent))
curFunc = curFunc == maxSeekerFuncs and 1 or curFunc + 1
coroutine.resume(processData, "task_complete")
if coroutine.status(processData) == "dead" then
coroutine.resume(displayProgress, "timer", myTimer)
break
end
end
end
The displayProgress / processData coroutines were previously additional (unnamed) functions in the scanfuncs table. They're now individually built directly as coroutines and resumed a single time each before this loop starts. Their contents could actually be dragged down
into this loop, but I'm lazy.
This code is built around the rule that displayProgress only ever requests timer events and the other coroutines only ever request task_complete events. A "regular" ComputerCraft-based coroutine manager would need to track what's being requested, but here the manager can safely make assumptions. Beats me how familiar you are with how coroutines work, but I'd like to imagine that
this snippet demonstrates most everything you need to know to understand the above.
